11institutetext: Indian Statistical Institute
11email<EMAIL_ADDRESS>
22institutetext: Cork University
22email<EMAIL_ADDRESS>33institutetext: University of Calcutta
33email<EMAIL_ADDRESS>
# AgEncID: Aggregate Encryption Individual Decryption of Key for FPGA
Bitstream IP Cores in Cloud

Mukta Debnath 11 Krishnendu Guha 22 Debasri Saha 33 Susmita Sur-Kolay 11

###### Abstract

Cloud computing platforms are progressively adopting Field Programmable Gate
Arrays (FPGAs) to deploy specialized hardware accelerators for specific
computational tasks. However, the security of FPGA-based bitstream for
Intellectual Property (IP) cores from unauthorized interception in cloud
environments remains a prominent concern. Existing methodologies for
protection of such bitstreams possess several limitations, such as requiring a
large number of keys, tying bitstreams to specific FPGAs, and relying on
trusted third parties. This paper proposes AgEncID (Aggregate Encryption and
Individual Decryption), a cryptosystem based on key aggregation to enhance the
security of FPGA-based bitstream for IP cores and to address the pitfalls of
previous related works. In our proposed scheme, IP providers can encrypt their
bitstreams with a single key for a set $S$ of FPGA boards, with which the
bitstreams can directly be decrypted on any of the FPGA boards in $S$.
Aggregate encryption of the key is performed in a way which ensures that the
key can solely be obtained onboard through individual decryption employing the
board’s private key, thus facilitating secure key provisioning. The proposed
cryptosystem is evaluated mainly on Zynq FPGAs. The outcomes demonstrate that
our cryptosystem not only outperforms existing techniques with respect to
resource, time and energy significantly but also upholds robust security
assurances.

###### Keywords:

Cloud environment FPGA Bitstream protection Key aggregation.

##  1 Introduction

Field-programmable gate arrays (FPGAs) are increasingly popular in cloud
environments due to their reconfigurability. Major cloud providers like IBM,
Oracle, Cisco, Microsoft, Amazon, and Google have integrated FPGA
reconfigurability into user applications [4]. Reconfiguring FPGAs with
different application cores at various times enables efficient task scheduling
and execution, resulting in high throughput, low latency, and low power
consumption. In public cloud environments, hardware IP cores are obtained from
various third-party vendors and deployed on FPGAs connected to the cloud.
Instead of users having to acquire these IP cores themselves, they simply
transmit their data to the cloud, where it is processed by the application
cores within the FPGAs and returned to the users. Safeguarding the
confidentiality of these FPGA-based bitstream for IP cores is a critical
security concern in this shared cloud environment to prevent unauthorized
access and tampering.

Table 1: Bitstream protection adopted by FPGA Vendors

FPGA vendors: | Xilinx | Altera | Microsemi
---|---|---|---
Devices: |  | Spartan-7,Artix-7,
---
Kintex-7, Virtex-7,
Zynq-7000
| Kintex Ultrascale,
---
Virtex Ultrascale,
Zynq Ultrascale
Arria 10 | Stratix 10 | SmartFusion2
Encryption: | AES-CBC 256 | AES-GCM 256 | AES-CTR 256 | AES-GCM 256 | AES-128/256
| Key
---
Storage:
| BBRAM/
---
eFUSE
| BBRAM/
---
eFUSE
| BBRAM/
---
eFUSE
| BBRAM/
---
eFUSE
| FLASH
---
SRAM-PUF
| Side-channel
---
Protection
Yes | Yes | Yes | Yes | Yes

###  1.1 Security Attacks on FPGA Bitstream in Cloud

FPGA bitstreams are vulnerable to various types of attacks when moving through
the cloud:

  * •

An attacker could copy bitstreams through a Man-in-the-Middle (MiM) attack and
sell them at a lower price to different cloud service providers. This not only
reduces the original provider’s profits and market share but also damages
their reputation.

  * •

An adversary might substitute genuine bitstreams with counterfeit ones through
reverse engineering (RE) or insert malicious code such as hardware trojan
horses (HTH). This could result in FPGA malfunctions or undesired results
[15].

  * •

The attacker could use side-channel analysis (SCA) to extract confidential
information from the bitstream, potentially revealing details about the FPGA’s
design or the underlying bitstream [22].

  * •

If the system software is compromised, it may contain malicious logic or HTH,
which could harm the bitstream’s performance, durability, or lead to the theft
of confidential design data [28].

###  1.2 Limitations in Existing FPGA Bitstream Protection Techniques

FPGA bitstream protection is typically achieved through bitstream encryption
to prevent unauthorized access, cloning, hardware Trojan insertions, reverse
engineering, and tampering attempts. Modern FPGAs, like those from Xilinx,
Intel, and Microsemi, support bitstream encryption using AES as listed in
Table 1, to defend against these types of passive attacks. Relying on vendor-
provided symmetric encryption (AES), several studies propose various
cryptosystems for encrypting, protecting, and verifying FPGA bitstreams [14,
1, 27]. However, those proposed cryptosystems vary in their approaches to
generating and handling cryptographic keys. Table 2 shows some notable prior
works in this area, along with where our contribution fits in. Furthermore,
various alternative methods [20, 18, 16, 7] have been suggested to address the
security issues. We identify four key limitations of these techniques for
securing bitstreams in cloud platforms:

  * •

Individual Encryption. IP providers use FPGA-specific encryption-decryption,
requiring developers to encrypt each bitstream for every FPGA, leading to
significant key management overhead of time and energy.

  * •

Tied to Specific FPGAs. Each bitstream is typically associated with a specific
FPGA board, limiting the cloud service providers’ ability to dynamically
allocate resources to meet varying customer demands.

  * •

Third-Party Involvement. Trusted third parties (TTPs) which play a role in
provisioning cryptographic keys to FPGAs, may give rise to unintentional
security vulnerabilities.

  * •

Resource Overhead. Existing solutions for key protection based on asymmetric
cryptographic involves intricate cryptographic operations on FPGAs or
necessitate changes to FPGA structures, often resulting in significant
resource demands in terms of hardware, time, and power consumption.

Table 2: Prior Works on FPGA Bitstream Protection

Works | Bitstream Encryption | Key Encryption |  FPGA Cloud |  TTP Required |  Change in FPGA |  Mapping (IP : FPGA)
---|---|---|---|---|---|---
Crypographic Technique | Protect Against |  Crypographic Technique | Protect Against
RE | Cloning | MiM | Tampering | SCA
Guneysu et al.[11] | AES-256 | ✓ | ✓ | ECDH | N/A | ✓ | ✓ | ✗ | ✓ | ✓ | 1:1
Drimer et al.[9] | AES-256 | ✓ | ✓ | ECDH; SHA-1 | N/A | ✓ | ✓ | ✗ | ✗ | ✓ | N:1
Eguro et al.[10] | AES-256 | ✓ | ✓ | RSA; SHA-256 | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | 1:1
Maes et al.[20] | AES-256 | ✓ | ✓ | H/W Metering | N/A | ✓ | ✓ | ✗ | ✓ | ✓ | 1:1
Boeui et al.[13] | AES-256 | ✓ | ✓ | RSA, ECC | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | 1:1
Khan et al.[17] | AES-256 | ✓ | ✓ | HAS | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | 1:1
Turan et al.[25] | AFGH PRE | ✓ | ✓ | H/W Metering | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | 1:N
Bag et al.[2] | AES-128 | ✓ | ✓ | KAC[12] | N/A | ✓ | ✓ | ✓ | ✗ | ✓ | N:1
AgEncID (ours) | AES-256 | ✓ | ✓ | Proposed Key Aggregation | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | 1:N

###  1.3 Our Contributions

To address the four limitations listed above, we presents AgEncID (Aggregate
Encryption and Individual Decryption), a cryptosystem centered around key
aggregation designed to safeguard FPGA bitstreams. AgEncID offers flexible key
management and secure provisioning of cryptographic keys. Below, we outline
the key features of AgEncID:

  * •

Single-Key Encryption. To overcome the first limitation, AgEncID allows IP
developers to encrypt their bitstream with a single key, which can be used to
decrypt the bitstream on a set of FPGA boards for execution. This
significantly reduces the time and energy cost of the system.

  * •

Decoupling from Specific FPGAs. IPs are not tied to specific FPGAs, enabling
cloud service providers to maximize resource utilization and flexibility. This
principle helps us to avoid second limitation.

  * •

No External TTP. To circumvent the third limitation, AgEncID eliminates the
need for a TTP—the bitstream protection key is known only to the bitstream
owner. The cryptographic components for key establishment is performed at the
FPGA vendor side who is usually considered to be trusted [13, 2].

  * •

Lower Overhead. AgEncID does not require changes to FPGA fabric or a dedicated
cryptographic processor on the FPGA, resulting in lower resource overhead.
Significant reduction in time, and power requirement is also achieved compared
to existing works. Therefore, AgEncID effectively tackles the fourth
limitation as well.

The rest of the paper is organized as follows. Section 2 presents system and
threat model for FPGA-based cloud system. Section 3 presents our proposed
$AgEncID$ along with its correctness especially in terms of key aggregation.
Section 4 discusses the application of AgEncID in FPGA-based cloud
environment. Its security and performance analysis appear in Section 5.
Experimental results are discussed in Section 6 with concluding remarks in
Section 7.

##  2 FPGA-based Cloud System

This section describes the system and threat models pertinent to an FPGA-based
cloud system.

Figure 1: FPGA-based cloud system model

###  2.1 System Model

In an FPGA-based cloud system, there are several key participants involved:
FPGA vendors (FVs), IP providers (IPPs), the Cloud Service Provider (CSP), and
the cloud users (CUs) as shown in Figure 1. The CSP is responsible for
deploying FPGAs from one or more FPGA vendors and offers them as a cloud
service to users [23]. To run applications on these cloud-connected FPGAs, the
CSP obtains IP cores from various third-party IP providers [26]. These IP
providers provide their designs in the form of HDL, netlists or bitstreams to
the cloud. Cloud users engage with this system by submitting their tasks to
the cloud, where application cores within bitstreams run on FPGAs, providing
Application-as-a-Service functionality. Multiple users’ workloads can share
the same physical resources in the cloud, depending on the CSP’s allocation
and scheduling policies. Typically, commercial CSPs allocate an entire FPGA
instance from a cloud-based pool to a single user [29], a model similar to
Amazon EC2 F1 (www.aws.amazon.com/ec2/instance-types/f1). In this setup, the
user gets dedicated allotment to the FPGA for a specified period according to
their demand and agreement with the cloud provider. However, they do not have
direct physical access to the FPGA hardware.

###  2.2 Threat Model

Given the various attacks at play (mentioned in Section 1.1), an individual
with malicious intentions has the potential to introduce multiple threats to
the integrity of the bitstream within the FPGA-based cloud system (Figure 1).
We considers the following threat scenarios on bitstream.

  * •

Malicious Cloud Service Provider. CSPs are not always trustworthy. CSPs can
access the RTL design of IP cores and engage in intellectual property (IP)
theft by bitstream reverse engineering.

  * •

Malicious Cloud User. Any potential adversaries among the other cloud users
who are not authorized for the bitstream usage can steal the bitstream and
misuse it without any administrative privileges.

  * •

Malicious IP Providers. The IPPs have access to privileged information about
the cloud system and may make efforts to intercept IP bitstreams from other
providers when their IPs are running on the same group of FPGAs.

  * •

Malicious External Agents. An external agent may attempts to gain unauthorized
access to a bitstream in transit within the cloud.

##  3 Aggregate Encryption Individual Decryption (_AgEncID_)

We introduce AgEncID (Aggregate Encryption and Individual Decryption), a
cryptosystem based on key aggregation to enhance the security of FPGA-based
bitstream IP cores. AgEncID comprises two modules: bitstream encryption module
and key aggregation module. The bitstream encryption module effectively
leverages vendor-provided symmetric encryption, particularly AES, which is
widely recognized and does not necessitate extensive elaboration. Our primary
focus lies on the key aggregation module of AgEncID, where we introduce a key
aggregation technique aimed at enhancing key management efficiency within
cloud environments and ensuring the secure provisioning of keys within cloud
FPGAs. In the subsequent section, we embark on a comprehensive exploration of
this proposed key aggregation method implemented within the AgEncID
cryptosystem.

###  3.1 Key Aggregation in AgEncID

The proposed key aggregation method of AgEncID relies on the utilization of
bilinear pairing on elliptic curves. A bilinear pairing is a bilinear map
defined over elliptic curve subgroups [3]. This concept is used in previous
works on broadcast encryption (BE) [6] and key aggregate cryptosystem (KAC)
[12].

Let $G$ and $G_{T}$ be two such (multiplicative) cyclic subgroups of prime
order $p$ and $\widehat{e}:G\times G\rightarrow G_{T}$ be a map with the
following properties:

  * Property 1. (bilinear) For every $g_{1},g_{2},g_{3}\in G$, we have
(i)
$\widehat{e}(g_{1}+g_{2},g_{3})=\widehat{e}(g_{1},g_{3})\cdot\widehat{e}(g_{2},g_{3})$;
(ii)
$\widehat{e}(g_{1},g_{2}+g_{3})=\widehat{e}(g_{1},g_{2})\cdot\widehat{e}(g_{1},g_{3})$.

  * Property 2. (efficiently computable) The map $\widehat{e}$ can be computed efficiently.

  * Property 3. (identity) For every $g\in G$, we have $\widehat{e}(g,g)=1$.

  * Property 4. (non-degenerate) For all $g\in G$, we have $e(g,h)=1$ for all points $h$ if and only if $h=\infty$.

  * Property 5. (alternation) $\widehat{e}(g_{1},g_{2})=\widehat{e}(g_{2},g_{1})^{-1}$ for every $g_{1},g_{2}\in G$.

The basic steps of the proposed key aggregation are inspired from KAC [12]
based on a public key cryptosystem. While KAC supports constant-size
ciphertexts and an aggregate key for decryption by a set of users, the
proposed key aggregation needs an aggregate key for encryption with individual
decryption keys. Thus a new aggregate key is generated with corresponding
encrypt and decrypt operations. The following operations are needed:

  * ➲

$\mathbf{Setup(1^{\lambda},n)}$ establishes the public cryptosystem parameters
$param$ for the entities, using their respective entity IDs $i$. Let $\lambda$
and $n$ be two positive integers, where $n$ denotes the number of entities,
and $1^{\lambda}$ the security level parameter. First, a bilinear group $G$ of
prime order $p$ where $2^{\lambda}\leq p\leq 2^{(\lambda+1)}$, a generator
$g\in G$ and $\alpha\in_{R}Z_{p}$ are chosen randomly. For
$i=\\{1,2....,n,n+2,...,2n\\}$, $g_{i}={\alpha^{i}}g$ are computed. So, output
the system parameter set as
$param=\\{g,g_{1},...,g_{n},g_{n+2},.....,g_{2n}\\}$.

  * ➲

$\mathbf{KeyGen(}n)$ produces
$PK=\\{g,g_{1},...,g_{n},g_{n+2},.....,g_{2n},v\\}$ as the master public key,
where $\gamma\in Z_{p}$ is chosen randomly such that the master-secret key
$msk=\gamma$ and $v={\gamma}g$. The $n$ private keys $d_{1},....,d_{n}$ for
each entity with IDs $i\in\\{1,2,.....,n\\}$ are given by
$d_{i}={\gamma}g_{i}={\alpha^{i}}v$, where $g_{i}\in G$, and $\alpha$ can be
safely deleted after $Setup$.

  * ➲

$\mathbf{Extract(S)}$ is used to generate a constant size aggregate key for
encryption. For a set of entities with their unique IDs $j\in S$, where
$S\subseteq n=\\{1,2,..,n\\}$ the aggregate key $K_{S}$ is computed as:

$K_{S}=\sum\limits_{j\in S}g_{n+1-j}$

  * ➲

$\mathbf{Encrypt(PK,S,K_{S},m)}$ is for encryption of a message $m$ (in this
case cryptographic key is been referred as message). For a plaintext message
$m\in G_{T}$ and set of entities with ID $j\in S$, $t\in_{R}Z_{p}$ is randomly
chosen. The ciphertext is computed for the set using its corresponding
aggregate key $K_{S}$. The cipher text $C=\\{c_{1},c_{2},c_{3}\\}$ comprises
of three parts: $c_{1}=tg$, $c_{2}=t(v+K_{S})$, and
$c_{3}=m(\widehat{e}(g_{n},tg_{1}))$.

  * ➲

$\mathbf{Decrypt(S,i,d_{i},C=(c_{1},c_{2},c_{3}))}$ is for decrypting the
ciphertext for an entity $i\in S$ using it’s unique decryption key $d_{i}$. If
$i\notin S$, then the output is $null$, otherwise, the decrypted message
$\widehat{m}$ is obtained as:

$\widehat{m}=c_{3}\cdot\frac{\widehat{e}(d_{i}\
+b_{i,S},c_{1})}{\widehat{e}(g_{i},\ c_{2})}$

where $b_{i,S}=\sum\limits_{(j\in S)\wedge(j\neq i)}g_{n+1-j+i}$.

###  3.2 Correctness of Key Aggregation in AgEncID

The correctness of the proposed key aggregation approach is founded upon the
assurance that decrypting the encrypted message will invariably yield the
original message. The following two lemmas grounded in the properties of
bilinear pairings play a crucial role.

###### Lemma 1

In the bilinear group $G$, with elements $g_{1}$ and $g_{2}$, and $a,b\in Z$,
the following equality holds:
$\widehat{e}(ag_{1},bg_{2})=\widehat{e}(g_{1},g_{2})^{ab}$.

###### Proof

Based on the bi-linear Property 1 as stated in section 3.1, we can write the
following:

$\displaystyle\widehat{e}(ag_{1},bg_{2})$
$\displaystyle=\widehat{e}\left(g_{1}+(a-1)\cdot g_{1},bg_{2}\right)$
$\displaystyle=\widehat{e}\left(g_{1},bg_{2}\right)\cdot\widehat{e}\left((a-1)\cdot
g_{1},bg_{2}\right)$ $\displaystyle\dots$
$\displaystyle=\widehat{e}\left(g_{1},bg_{2}\right)^{a}$ (1)

Iterating in a similar manner with $b$-steps on Eqn. 1, we have the following:

$\displaystyle\widehat{e}\left(g_{1},bg_{2}\right)^{a}$
$\displaystyle=\widehat{e}\left(g_{1},g_{2}\right)^{ab}$

Therefore, we can conclude that,

$\displaystyle\widehat{e}(ag_{1},bg_{2})$
$\displaystyle=\widehat{e}\left(g_{1},g_{2}\right)^{ab}$ ($\blacksquare$)

###### Lemma 2

For every $g_{1},g_{2},g_{3}\in G$, the following relationship holds:

$\displaystyle\widehat{e}(g_{1}-g_{2},g_{3})=\frac{\widehat{e}(g_{1},g_{3})}{\widehat{e}(g_{2},g_{3})}$

###### Proof

BY Property 1 (bilinear) in Section 3.1, we can express as follows:

$\displaystyle\widehat{e}(g_{1}-g_{2},g_{3})$
$\displaystyle=\widehat{e}(g_{1}+(-g_{2}),g_{3})$
$\displaystyle=\widehat{e}(g_{1},g_{3})\cdot\widehat{e}(-g_{2},g_{3})$
$\displaystyle=\widehat{e}(g_{1},g_{3})\cdot\widehat{e}(-1\cdot g_{2},g_{3})$
(2)

By applying Lemma 1 with $a=-1$ and $b=1$, we can rephrase Eqn. 2 as:

$\displaystyle\widehat{e}(g_{1},g_{3})\cdot\widehat{e}(-1\cdot g_{2},g_{3})$
$\displaystyle=\widehat{e}(g_{1},g_{3})\cdot\widehat{e}(g_{2},g_{3})^{-1}$ (3)

Therefore, based on equations 2 and 3, we can deduce that:

$\displaystyle\widehat{e}(g_{1}-g_{2},g_{3})$
$\displaystyle=\frac{\widehat{e}(g_{1},g_{3})}{\widehat{e}(g_{2},g_{3})}$
($\blacksquare$)

###### Theorem 3.1

(Correctness of Key Aggregation in $AgEncID$) The decryption of an encrypted
message yields precisely the original message $m$.

###### Proof

Consider $\widehat{m}$ as the decrypted message corresponding to the original
message $m$. According to operations of proposed key aggregation module
mentioned earlier,

$\displaystyle\widehat{m}$
$\displaystyle=c_{3}\cdot\frac{\widehat{e}\left(\left(d_{i}+\sum\limits_{(j\in
S\wedge j\neq i)}g_{n+1-j+i}\right),c_{1}\right)}{\widehat{e}(g_{i},c_{2})}$
(4)

By substituting values from key aggregation method’s operations, we can
express Eqn. 4 as:

$\displaystyle\widehat{m}$
$\displaystyle=c_{3}\cdot\frac{\widehat{e}\left(\left({\gamma}g_{i}+\sum\limits_{j\in
S}g_{n+1-j+i}-g_{n+1}\right),\
tg\right)}{\widehat{e}\left(g_{i},t\left(pk+\sum\limits_{j\in
S}g_{n+1-j}\right)\right)}$

$\displaystyle=c_{3}\cdot\frac{\widehat{e}({\gamma}g_{i},tg)\widehat{e}\left(\sum\limits_{j\in
S}\
g_{n+1-j+i}-g_{n+1},tg\right)}{\widehat{e}(g_{i},t{\gamma}g)\widehat{e}\left(g_{i},t\sum\limits_{j\in
S}g_{n+1-j}\right)}$ (by Property 1)
$\displaystyle=c_{3}\cdot\frac{\widehat{e}\left(\sum\limits_{j\in
S}g_{n+1-j+i},tg\right)}{\widehat{e}\left(tg,\sum\limits_{j\in S}\
g_{n+1-j+i}\right)\widehat{e}(g_{n+1},tg)}$ (using Lemma 1 and 2)
$\displaystyle=c_{3}\cdot\frac{1}{\widehat{e}(g_{n+1},tg)}$ (by Lemma 2)
$\displaystyle=m\cdot\frac{\widehat{e}(g_{n},tg_{1})}{\widehat{e}(g_{n+1},tg)}$
(by Property 1) (5)

By applying Diffie-Hellman Exponent assumption [5]
($\widehat{e}(g_{1},g_{n})=\widehat{e}(g,g_{n+1})$) on Eqn. 5,
$\widehat{m}=m\cdot\frac{\widehat{e}(g_{n},tg_{1})}{\widehat{e}(g_{n},tg_{1})}=m$.
This establishes the correctness of the encryption and decryption algorithms
of the proposed key aggregation module of $AgEncID$. ($\blacksquare$)

Figure 2: An overview of key aggregation method of $AgEncID$

###  3.3 A Working Example

Figure 2 shows a general illustration of how AgEncID cryptosystem works in
terms of key aggregation. Here, AgEncID follows a public-key cryptosystem. It
creates a fixed-size encryption key for a message that needs to be encrypted
for various entities, each having its own unique identity ID. However, it
ensures that each entity has its own separate decryption key. Given a
plaintext message, $msg_{1}$, to be encrypted for a set of $n$ entities with
IDs $i=1,2,..,n$, it is possible to generate a constant-size aggregate
encryption key $Ks$, for any arbitrary subset $S$ of the IDs,
$S\subseteq\\{1,2,..,n\\}$. The ciphertext can be decrypted by an entity with
ID $j$ such that $j\in S$ using its private individual decryption key $d_{j}$.
Figure 2 illustrates the $AgEncID$ scheme with two sets of entities
represented by their unique IDs in $S_{1}=\\{1,3\\}$ and $S_{2}=\\{2,4\\}$.
The entity administrator generates the master public key $PK$ and aggregate
keys $Ks_{1,3}$ (for$S_{1}$) and $Ks_{2,4}$ (for $S_{2}$). These keys are then
employed to encrypt the plaintext message $msg_{1}$ for both $S_{1}$ and
$S_{2}$. The entity administrator also generates the master secret key $msk$,
which is used to construct the individual decryption keys. The ciphertext
$C_{1}$ for the message $msg_{1}$ can be decrypted by entities from $S_{1}$
using their individual decryption key $d_{1}$ and $d_{3}$ but fails to be
decrypted by entities from $S_{2}$ or any other entity set.

##  4 AgEncID in FPGA Cloud Environment

This section explains how _AgEncID_ works in an FPGA-cloud environment using
Algorithm 1. While a cloud system can have multiple FPGA vendors (FVs), each
providing a number of FPGA boards, and IP providers (IPPs), each providing one
or more IP cores, here we focus on the communication among a CSP, an FV and an
IPP using $AgEncID$ and provide an example (Figure 3). In order to achieve a
resemblance with Figure 2, we can align FPGA boards and FPGA vendors with
entities and the entity administrators depicted in the figure.

Figure 3: An example of AgEncID’s working principle with one FV and one IPP in
FPGA Cloud Environment

Cluster Formation for FPGAs. Cluster Formation for FPGAs involves the CSP
grouping FPGA board requirements based on FVs and board families. We consider
three scenarios:
Scenario 1: A cluster with $n$ boards from the same FV and family.
Scenario 2: A cluster with $n$ boards from the same FV but with $m$ different
families, $m\leq n$.
Scenario 3: A cluster with $n$ boards from various FVs, potentially containing
scenarios 1 and 2 within each FV.
Table 3 compares the number of cryptographic operations required by AgEncID
with naive approaches that do not involve cluster formation. A naive approach
requires individual encryption and decryption for both symmetric bitstream
encryption and asymmetric key encryption for each board. AgEncID performs best
in scenario 1. In scenario 2, the number of AgEncID operations increases with
more families ($m$), and in scenario 3, AgEncID is less efficient, with the
number of operations depending on the number of FVs and their board families
in a cluster. Our primary focus is on discussing AgEncID within scenarios 1
and 2. For example, Figure 3 shows how $n=5$ boards are grouped into two
clusters: $Cluster1$ for scenario 1 and $Cluster2$ for scenario 2 within one
FV.

Table 3: Possible cluster scenarios for $n$ FPGA boards of $m$ families along
with
the number of operations needed by _AgEncID_ vs._Naive_ approaches

Operation | Scenario 1 | Scenario 2
---|---|---
Naive Solution | AgEncID Solution | Naive Solution | AgEncID Solution
| Bitstream
---
Encrypt
| Key
---
Encrypt
| Bitstream
---
Encrypt
| Key
---
Encrypt
| Bitstream
---
Encrypt
| Key
---
Encrypt
| Bitstream
---
Encrypt
| Key
---
Encrypt
Key Generation | $=n$ | $=n$ | $\mathbf{=1}$ | $\mathbf{=1}$ | $=n$ | $=n$ | $\mathbf{=1}$ | $\mathbf{=1}$
Encryption | $=n$ | $=n$ | $\mathbf{=1}$ | $\mathbf{=1}$ | $=n$ | $=n$ |  $\mathbf{\geq m}$, $\mathbf{\leq n}$ | $\mathbf{=1}$
Decryption | $=n$ | $=n$ | $=n$ | $=n$ | $=n$ | $=n$ | $=n$ | $=n$

Initial Setup and Key Generation. The asymmetric key generation for the
$AgEncID$’s key aggregation module are primarily conducted by the FVs. First,
the FV creates the unique board IDs for each of the boards supplied by
her/him, that are hashed to index $i$ such that $i\in{{1,2,3,...,n}}$ and
generates the public parameters based on these board IDs. The FV generates a
public key $PK$, a master secret key $msk$ for $AgEncID$ and the private keys
$d_{i}^{\prime}s$ for the $n$ boards. Additionally, FV generates the aggregate
key $AgK_{Sj}$ for each cluster. As shown in Figure 3, the FV receives request
for $n$ boards divided into two clusters of boards IDs $j$, $Cluster_{1}$ with
$S_{j}=\\{1,3,4\\}$ and $Cluster_{2}$ with $S_{j}=\\{2,5\\}$. While Setup()
and KeyGen() operations are performed one-time for all $n$ boards, the FV must
execute the Extract() operation for each cluster separately. Subsequently, the
FV transfers the public key $PK$ of all $n$ boards along with the
corresponding $AgK_{Sj}$ keys for each cluster to the CSP. In order to enhance
security, the FV embeds the private keys $d_{i}^{\prime}s$ into a tamper-proof
non-volatile memory segment of the boards. Finally, each FPGA is equipped with
the $AgEncID$ decryption core.

Algorithm 1 Aggregate Encryption Key Individual Decryption Key — $AgEncID$
Cryptosystem

1:procedure InitialSetup and KeyGeneration(FPGA-BOARDS) $\triangleright$ By
FVs

2: for each FPGA do

3: Assign a unique ID to each of the $n$ FPGA boards

4: end for

5: $(param)\leftarrow AgEncID.setup(n)$ $\triangleright$ generates the
_AgEncID_ cryptosystem parameters

6: $(PK,msk)\leftarrow AgEncID.KeyGen(n)$ $\triangleright$ generates the keys
for _AgEncID_ system

7: Let $N$ denote the set of all IDs for $n$ FPGA boards

8: for each $ID\in N$ do

9: Generate the board specific private keys $d_{i}^{\prime}s$

10: Embed $d_{i}$ in a tamper-proof non-volatile memory segment

11: end for

12: Each FPGA is provisioned with a _AgEncID_ decryption engine

13: Let $S$ denote the set of all ID-s for a cluster of FPGA boards
$S\subseteq N$

14: for each $ID\in S$ do

15: $AgK_{S}\leftarrow AgEncID.Extract(S)$ $\triangleright$ $AgK_{S}$ is
aggregate key for encryption

16: end for

17: Register the $n$ FPGAs with CSP in clusters along with their $PK$ and
$AgK_{S}$s

18:end procedure

19:

20:procedure Encryption(Bitstream) $\triangleright$ Performed by IP Providers

21: An IP Provider is assigned with a cluster $S$ of board $IDs$ by CSP

22: $K_{S}\leftarrow AES.KeyGen$ $\triangleright$ $K$ is one-time AES key for
$S$ boards

23: $EncBit_{S}\leftarrow AES.Encrypt(Bitstream,K_{S})$ $\triangleright$
encrypted bitstream

24: $EncK_{S}=(k_{1},k_{2},k_{3})\leftarrow
AgEncID.Encrypt(PK,S,AgK_{S},K_{S})$ $\triangleright$ encrypted key

25: Upload encrypted bitstream $EncBit_{S}$, ciphertext key triple $EncK_{S}$
in cloud

26:end procedure

27:

28:procedure BitstreamDecryption(Encrypted-Bitstream)

29: $K_{S}\leftarrow AgEncID.Decrypt(S,i,d_{i},EncK_{S}=(k_{1},k_{2},k_{3}))$
$\triangleright$ Decrypted AES key

30: $bitstream\leftarrow AES.Decrypt(EncBit_{S},K_{S})$ $\triangleright$ The
original bitstream

31:end procedure

Encryption. The IPP receives requests from the CSP to run IP on a group of
boards. Initially, the IPP creates an encrypted bitstream for the design using
its unique AES key specifically for that cluster of boards. Figure 3 shows IPP
encrypting the bitstream for $Cluster_{j}$. Following that, the IPP encrypts
the AES key itself using the aggregate key it received for that cluster,
$AgK_{Sj}$. The IPP sends both the encrypted bitstream $EncBit$ and the
encrypted AES key $EncKey$ to the cloud resource pool. Importantly, this
encrypted bitstream can only be decrypted on the FPGA boards within
$Cluster_{j}$.

Decryption. When a cloud user requests a task, the CSP handles the request and
forwards the appropriate bitstream to an available FPGA board. In the
decryption process, the board’s private key is used for on-board decryption to
obtain the AES key, which is then employed within the board’s AES decryption
core to decrypt the bitstream (depicted in Figure 3 for $Cluster_{1}$).
Finally, the FPGA is set up with the decrypted bitstream, and the resulting
output is delivered to the user.

##  5 Analysis of $AgEncID$ Security and Performance

In this section, we delve into the security and performance aspects of the
AgEncID framework.

###  5.1 $AgEncID$ Security

The proposed AgEncID offers security against the threat model described in
Section 2.2. The security of $AgEncID$ relies on the security of the AES-256
cipher and the key aggregation scheme. AES-256 is a strong encryption
algorithm that has been subjected to extensive cryptanalysis and no
significant weaknesses have been found. AES-256 key is protected by $AgEncID$
with an elliptic curve (EC)-based construction that is provably secure against
chosen plaintext attacks (CPAs) on the key [12] under the discrete logarithm
problem (DLP) in EC and the bilinear Diffie-Hellman exponent (BDHE) problem
[21]. The public and secret key parameters for the _AgEncID_ system are
protected under the security assumptions of DLP in EC and BDHE [6].

Security of Bitstream. The bitstream is encrypted with AES-256 by IPP using
its own key and sent to the CSP over secure channels such as SSL or TLS to
prevent interception through _MiM_ attacks. The AES-256 encryption provided by
major FPGA vendors is resistant to conventional attacks such as _cloning_ ,
_RE_ , unauthorized copying of the bitstream, and _tampering_. Decryption of
the bitstream is exclusively possible on the FPGA chip, using the AES key
known only to its owner. This AES key is further encrypted with AgEncID,
ensuring that it can only be decrypted on-chip using FPGA’s embedded private
key. Hence, neither the CSP nor a malicious external entity can access the
unencrypted bitstream. Even if IPPs and CUs were to collude in an attempt to
expose other authorized IPPs or CUs’ bitstreams, their efforts would be
futile. Accessing the AES key is only feasible on the FPGA chip itself, and
the storage and operations on these FPGAs are considered highly secure. The
vendors claim that their FPGAs can defend against attacks that occur while the
FPGA is operating, such as _SCA_ and the leakage of protected information
across internal boundaries.

Security of Key. In the AgEncID framework, the AES key provisioning to the
FPGA is highly secure, thwarting unauthorized interception. The AgEncID
scheme’s CPA-secure nature makes it exceptionally resilient, even if the
encrypted key is compromised. This key is stored securely alongside the
bitstream in the cloud, albeit vulnerable to potential MiM attacks during
transit. Decryption relies on the device-specific private key inside the
secure FPGA storage. This key is inaccessible to everyone, including the CSP
and IPPs. Additionally, the key provisioning process does not involve TTPs,
which reduces the risk of MiM attacks. AES key decryption occurs on the FPGA
through AgEncID, with the decrypted key briefly stored in Battery-Backed RAM
(BBRAM), reliant on continuous power for data retention. Tampering attempts
lead to power cuts, erasing BBRAM and the FPGA configuration, preventing Side-
Channel Attacks (SCA) and tampering[24]. Additionally, Xilinx (AMD) ensures
that the key cannot be read or reprogrammed externally once programmed,
limiting access solely to the internal bitstream decryption engine
(www.docs.xilinx.com/v/u/en-US/xapp1239-fpga-bitstream-encryption). Cloud-FPGA
communication employs secure protocols, granting CSP logical access for
processing without hardware access. IPs are provided to users as an
Application-as-a-Service, eliminating external network connections and
mitigating side-channel attack risks. While this work doesn’t address high-
level adversaries targeting FPGA fabrics, it establishes robust security.
AgEncID guarantees that the AES key remains inaccessible to any unauthorized
individuals, including CUs and external agents.

###  5.2 AgEncID Performance and Efficiency

The AES algorithm has the same computational complexity as naive AES-256. We
discuss the algorithmic efficiency of the key aggregation method of AgEncID
below.

Low overhead Key Generation. $AgEncID.setup()$ operation has a cost of
$\mathcal{O}(|n|)$ for generating the cryptosystem parameters of size
$\mathcal{O}(|n|)$. The size of the public key, which depends on these
parameters, scales linearly with the total number of FPGA boards. This is
generally manageable in organizations with ample shared storage. Each board is
assigned a private key consisting of just one group element, resulting in low
and constant-size private keys. A single AES key is used to encrypt bitstreams
for a cluster of $|S|\leq n$ boards. Extracting the fixed size aggregate key
for encrypting AES keys for $|S|\leq n$ boards requires $\mathcal{O}(|S|)$
group additions and is of fixed size. Consequently, AgEncID’s key generation
is both time and space-efficient.

Efficient Encryption and Decryption. Encryption doesn’t require pairing
operations, the pre-computed value $\hat{e}(g_{n},tg_{1})$ can be quickly
processed at a constant rate. The resulting ciphertext is compact in size.
Decryption, on the other hand, involves $\mathcal{O}(|S|)$ additions in the
group and two pairing operations. Recent high-speed software implementations
(www.crypto.stanford.edu/pbc, www.github.com/herumi/mcl, etc.) enable fast
bilinear pairing computations, even when employed on devices with limited
computational resources. Furthermore, both the encryption and decryption
routines in AgEncID require a fixed number of elliptical curve operations.

Flexible Resource Management by CSP. The CSPs should have the flexiblity in
provisioning bitstreams and keys to FPGAs. $AgEncID$ encryption scheme allows
IPPs to encrypt their bitstreams and their keys for a set of FPGAs as
requested by CSP. Thus CSPs can manage the FPGAs and assign different FPGAs to
users at each run in the cloud according to resource availability.

###  5.3 Discussion

The CSP may wish to add more FPGAs in the cloud to satisfy users’ demands. In
such a scenario, the CSP would contact the FV for a new board registration
with the cloud. The FPGA vendor then manages the $AgEncID$ parameters for a
new board. Dynamic board registration at the FPGA vendor side is managed
through the unique board IDs $i$ that belongs to a set $S$. The FV maintains a
flag to monitor availability of previously assigned $i$ in case of de-
registration of a board from the set $S$. Available board IDs $i$’s are
assigned to the new boards dynamically during board registration. In such a
scenario, the public key $PK$ does not need to be updated. With a new board
registrations under new ID, the FV expands the public key $PK$ by simply
adding two more elements to the $param$ of $PK$. The secret parameter $\alpha$
during setup is randomly generated. $\alpha$ is made event driven and
generated whenever a new board is registered. Thus the CSP need not contact
the IP developer to use their IP on the newly added FPGAs unless a new board
ID is added in $S$.

##  6 Experiments and Evaluation

###  6.1 Experimental Setup

Experiments are performed on 64-bit linux machine, having Intel Core i5
processor and 16 GB RAM clocked at 3.2 GHz. For our evaluation, we utilized
five Xilinx boards from various families, as indicated in Table 4. Vivado
Design Suite is used to generate bitstream from a HDL design and perform
simulations. A pairing friendly elliptic curve construction is needed for the
bilinear group mapping. We have used Type-A curves bundled with Pairing-Based
Cryptography, PBC version 0.5.14 (www.crypto.stanford.edu/pbc). Four
properties of the curve used for symmetric bilinear pairing are: (i) Type A
supersingular curve $y^{2}=x^{3}+x$; (ii) $160$-bit Solinas prime number _p_ ,
which offers $1024$-bit of discrete-logarithm security; (iii) the embedding
degree $k$ of pairing is $2$; (iv) elements of group $G$ and $G_{T}$ take
$512$ and $1024$ bits respectively.

Table 4: Properties of FPGA boards used in Experiments

No. | Board | Family | Device | Processor | Memory
---|---|---|---|---|---
B1 | ZC702 |  F1 Zynq-7000 | XC7Z020-CLG484-1 | Dual ARM Cortex-A9 core | 1GB DDR3
B2 | PYNQ-Z2 | XC7Z020-1CLG400C | Dual ARM® Cortex™-A9 MPCore™ |  | 256 KB on-chip,
---
8 GB SD card
B3 | Zybo-Z7 | XC7Z020-1CLG400C | Dual-core ARM Cortex-A9 | 1 GB DDR3L
B4 | ZCU104 |  | F2
---
Zynq UltraScale+ MPSoC
XCZU7EV-2FFVC1156 |  | quad-core ARM® Cortex™-A53,
---
Dual-core Cortex-R5
PS DDR4 2GB
B5 | KC705 |  | F3
---
Kintex 7
XC7K325T-2FFG900C | MicroBlaze, 32bit RISC | 1GB DDR3 SODIM

###  6.2 Implementation and tools used

Our scheme relies on two cryptographic modules: the standard _AES_ cores
offered by FPGA vendors and the key aggregation cores of _AgEncID_. In this
section, we’ll describe how we implemented and utilized these modules within
the _AgEncID_ framework, including the tools we employed.

Key Generation and Encryption. To generate the 256-bit AES encryption key for
encrypting a bitstream, standard tools and techniques can be employed. In our
case, we used Vivado to create the specific AES key provided by the vendor.
Bitstream encryption was carried out using the default AES-256 encryption
feature available in Xilinx Vivado. To encrypt the 256-bit AES key, we
utilized $AgEncID$’s key aggregation encryption module. This module is
implemented in software using the GNU multiple precision arithmetic library
(GMP) (www.gmplib.org, version 6.2.1) and the PBC Library
(www.crypto.stanford.edu/pbc). PBC Library is used for the underlying
elliptic-curve group and pairing operations. PBC provides the necessary APIs
to compute pairings over the BN family of elliptical curves. The
$\mathbf{Encrypt(PK,S,K_{S},m)}$ operation of key aggregation module in
_AgEncID_ is implemented through three primary operations: point addition,
point doubling and pairing with CPU latencies of $3.01\times 10^{-3}$ ms,
$6.2\times 10^{-3}$ ms and $19.4$ ms respectively.

Figure 4: Flowchart for $AgEncID$’s $Decrypt()$ operation in key-aggregation
module

Decryption. Similar to the encryption phase, the decryption process in AgEncID
also consists of two parts: key decryption and bitstream decryption. For key
decryption, the $\mathbf{Decrypt(S,i,d_{i},C=(c_{1},c_{2},c_{3}))}$ operation
of $AgEncID$’s key aggregation module involves elliptic curve pairing
operations. For the decryption operation we utilize an embedded processor core
in the Processing System (PS) section (eg. B1-B4 in Table 4) of modern SoCs.
This decryption module leverages the same libraries (GMP and PBC) used for
$AgEncID$’s $Encrypt()$ operation, and is deployed in the PS region of the
FPGAs (as shown in Figure 4). On $ARMCortex-A9$ processors from the
$Zynq-7000$ family, this software module takes $401$ ms to decrypty an AES-256
key. For SoCs lacking an embedded processor core in the PS, we’ve developed a
hardware core for $AgEncID$’s $Decrypt()$ operation written in Verilog. This
core can be deployed in the Programmable Logic (PL) of the FPGA. It implements
a pairing-friendly elliptic curve providing a 256-bit security level [3],
including point addition and scalar multiplication operations. The bilinear
pairing core used is inspired by the Duursma-Lee algorithm [19] for pairing
operations. For bitstream decryption, we utilize the on-chip AES decryption
module provided by vendors. This module has standard resource
requirements—Xilinx AES decryption core
(www.xilinx.com/htmldocs/ip_docs/pru_files/aes.html).

###  6.3 Results and Evaluation

We evaluate the effectiveness of the _AgEncID_ cryptosystem in three key
aspects: (i) execution time, (ii) energy consumption in terms of CPU usage,
and (iii) FPGA resource overhead. To gauge its performance, we compared it
with the one-to-one mechanism used in existing approaches, referred as IEID
(Individual Encryption Individual Decryption). Our evaluation for bitstream
encryption was conducted using a set of experiments on bitstreams generated
for the ISCAS (www.sportlab.usc.edu/~msabrishami/benchmarks.html) benchmark
circuits On the other hand, key encryption is performed on 256-bit AES key. We
conduct following experiments:

  * •

Experiment 1. We conducted bitstream encryption for a cluster of $20$ boards,
representing scenario 1, using _AgEncID_ and _IEID_. We used the $C17$
benchmark design and selected the $20$ boards from the F1 family
(specifically, boards B1, B2, and B3), as listed in Table 4.

  * •

Experiment 2. Bitstream encryption was carried out on $C17$ for scenario 2. A
cluster of $10$ boards are chosen from three different families F1, F2, and F3
as listed in Table 4, i.e $n=10$ and $m=3$. We take $3$ boards from F1 and F2
each and $4$ boards from F3. We again compared the AgEncID approach with the
IEID approach.

  * •

Experiment 3. We performed bitstream encryption for a cluster of $5$ boards,
depicting scenario 1, using both the _AgEncID_ and _IEID_ approaches. We
evaluated on three benchmark designs of varying sizes: $C432$, $C499$, and
$C880$.

  * •

Experiment 4. We performed 256-bit AES key encryption using key aggregation
module of AgEncID for $20$ boards, covering scenarios 1 and 2. Additionally,
we performed 256-bit AES key encryption by altering key aggregation module of
_AgEncID_ according to _IEID_ framework.

51015200510152025Number of BoardsExecution Time (s)AgEncIDIEID (a)

24681005102030Number of BoardsExecution Time (s)AgEncIDIEID (b)

C432(48MB)C499
(60MB)C880(111MB)$0$$5$$10$$15$$20$$25$$30$$35$$40$$45$$50$Design bitstream
with sizeExecution Time (s)AgEncIDIEID (c)

Figure 5: Execution time of AgEncID and IEID for bitstream encryption

Execution Time. In Figure 5, we depict the CPU execution time for AgEncID’s
AES bitstream encryption. In Figure 5 (a), we observe that AgEncID
consistently requires the same amount of time in Experiment 1, in contrast to
the IEID approach, where the time increases linearly as the number of boards
increases. Figure 5 (b) depicts that AgEncID’s time requirement varied for AES
encryption within the different board families (Experiment 2). Despite the
differing time requirements, the AgEncID approach maintains its superiority
over the IEID approach. In Experiment 2, AgEncID’s performance is similar to
IEID for bitstream encryption when $n=m$. Figure 5 (c) depicts a significant
$5X$ time difference between IEID and AgEncID in Experiment 3, which
represents a substantial cost when handling large bitstreams. These results
are derived from Vivado CPU timing report. For both scenarios 1 and 2, AgEncID
maintains a constant time requirement in Experiment 4, unlike IEID that
requires individual key encryption for each board. Figure 7 (a) illustrates
that symmetric key generation is performed at a constant time by AgEncID for
any number of boards, in contrast to IEID approach. Figure 7 (b) provides
timing results for Experiment 4, indicating the constant CPU time needed for
executing AgEncID’s key encryption algorithm unlike IEID that requires
individual key encryption for each board.

51015200102030Number of BoardsEnergy Consumption (J)AgEncIDIEID (a)

2468105101520Number of BoardsEnergy Consumption (J)AgEncIDIEID (b)

C432 (48MB)C499 (60MB)C880 (111MB)$0$$10$$20$$30$$40$$50$$60$$70$$80$Design
bitstream with sizeEnergy Consumption (J)AgEncIDIEID (c)

Figure 6: Energy consumption by AgEncID and IEID for bitstream encryption

Energy Consumption. Figure 6 illustrates the comparison between _AgEncID_ and
IEID approaches in terms of energy consumption for Experiment 1, similar to
the comparison of their respective execution times. From Figure 6 (a), it is
evident that _AgEncID_ consistently demonstrates superior energy efficiency
over _IEID_ , regardless of the number of boards in the cluster. Furthermore,
Figure 6 (c) highlights the energy requirements for _AgEncID_ and _IEID_ in
Experiment 3, showcasing substantial energy savings achieved by _AgEncID_.
These energy calculations are obtained from the Vivado CPU power consumption
report. The results for Experiment 2 and Experiment 4 for energy consumption
is similar to that of execution time which is depicted in Figure 6 (b) and
Figure 7(c) respectively. Similar to execution time, when it comes to energy
consumption, key encryption demonstrates significantly lower resource
utilization compared to bitstream encryption.

5101520010203040Number of BoardsExecution Time (ms)AgEncIDIEID (a)

5101520050100150200Number of BoardsExecution Time (ms)AgEncIDIEID (b)

51015200246Number of BoardsEnergy Consumption (J)AgEncIDIEID (c)

Figure 7: AgEncID vs IEID in terms of key generation and aggregation

FPGA Resource Overhead. AgEncID’s key aggregation algorithm primarily operates
in external software, reducing FPGA resource demands. Encryption tasks are
conducted externally to the FPGA. The FPGA only loads the symmetric AES key
when necessary. A few kilobytes (KBs) is required for the board-specific
private key and AgEncID’s key decryption module running in the processor core
of PS. Depending on device availability and licensing, we’ve deployed the
AgEncID’s key decryption module on PL of board $B1$ ( Table 4). In Table 5, an
overview of FPGA’s resource utilization, latency and power consumption of
AgEncID hardware decryption module is reported. Directly comparing FPGA
resource overhead of AgEncID with existing techniques is challenging due to
differences in evaluation environments and FPGA features. However, in terms of
parameters such as LUTs, Registers, and Slices, $AgEncID$’s resource overhead
typically falls in the range of $2$% to $17$%, whereas related works have
resource overhead ranging from $2$% to $51$% [10, 8, 2].

Table 5: Resource utilization, storage, performance and power consumption
report for _AgEncID_ ’s $Decrypt()$ operation of key-aggregation, on ZC702

Module | Resource Utilization | Storage (KB) | Performance | Power (Watt)
---|---|---|---|---
|  | LUTs
---
| Registers
---
| Slices
---
|  | # Clock Cycles
---
| Latency (ns)
---
ECC |  $1181$ (#) |  $1403$ (#) |  $503$ (#) | $7695.402$ | $2415$ | $6.667$ | $0.114$
$2.21$ (%) |  $1.32$ (%) |  $3.78$ (%)
Pairing |  $7608$ (#) |  $13401$ (#) |  $1668$ (#) | $8119.027$ | $57456$ | $20$ | $0.192$
$14.35$ (%) |  $12.59$ (%) |  $12.54$ (%)

##  7 Conclusion

This paper present AgEncID (Aggregate Encryption and Individual Decryption)
cryptosystem for FPGA bitstream protection through secure key provisioning.
AgEncID employs a new key aggregation technique and a streamlined encryption-
decryption process to significantly reduce the resource overhead (storage,
time, and energy) of both key and bitstream encryption, compared to existing
methods. In the future, we plan to implement cutting-edge cryptographic
algorithms to address threats arising from advanced on-board FPGA attacks and
large-scale quantum computing attacks.

## References

  * [1] Alkabani, Y.M., Koushanfar, F.: Active hardware metering for intellectual property protection and security. In: Proceedings of 16th USENIX Security Symposium on USENIX Security Symposium (2007)
  * [2] Bag, A., Patranabis, S., Roy, D.B., Mukhopadhyay, D.: Cryptographically secure multi-tenant provisioning of fpgas. In: Security, Privacy, and Applied Cryptography Engineering (2020)
  * [3] Barreto, P.S.L.M., Naehrig, M.: Pairing-friendly elliptic curves of prime order. In: SAC (2006)
  * [4] Bobda, C., et al.: The future of fpga acceleration in datacenters and the cloud. ACM Transactions on Reconfigurable Technology and Systems (2022)
  * [5] Boneh, D., Boyen, X., Goh, E.J.: Hierarchical identity based encryption with constant size ciphertext. In: Eurocrypt (2005)
  * [6] Boneh, D., Gentry, C., Waters, B.: Collusion resistant broadcast encryption with short ciphertexts and private keys. In: CRYPTO (2005)
  * [7] Chakraborty, R.S., Bhunia, S.: Rtl hardware ip protection using key-based control and data flow obfuscation. In: 2010 23rd International Conference on VLSI Design (2010)
  * [8] Drimer, S., Güneysu, T., Kuhn, M.G., Paar, C.: Protecting multiple cores in a single fpga design. Draft (2008), https://saardrimer.com/sd410/papers/protect_many_cores.pdf
  * [9] Drimer, S., Kuhn, M.G.: A protocol for secure remote updates of fpga configurations. In: Reconfigurable Computing: Architectures, Tools and Applications (2009)
  * [10] Eguro, K., Venkatesan, R.: Fpgas for trusted cloud computing. In: FPL) (2012)
  * [11] Guneysu, T., Moller, B., Paar, C.: Dynamic intellectual property protection for reconfigurable devices. In: FPT (2007)
  * [12] Guo, C., Luo, N., Bhuiyan, M.Z.A., Jie, Y., Chen, Y., Feng, B., Alam, M.: Key-aggregate authentication cryptosystem for data sharing in dynamic cloud storage. Future Generation Computer Systems (2018)
  * [13] Hong, B., Kim, H.Y., Kim, M., Suh, T., Xu, L., Shi, W.: Fasten: An fpga-based secure system for big data processing. IEEE Design & Test (2018)
  * [14] Hoque, T., et al.: Hidden in plaintext: An obfuscation-based countermeasure against fpga bitstream tampering attacks. ACM Transactions on Design Automation of Electronic Systems (2019)
  * [15] Jin, C., Gohil, V., Karri, R., Rajendran, J.: Security of cloud fpgas: A survey. ArXiv (2020)
  * [16] K., S.K., Sahoo, S., Mahapatra, A., Swain, A.K., Mahapatra, K.: A flexible pay-per-device licensing scheme for fpga ip cores. In: 2017 IEEE Computer Society Annual Symposium on VLSI (ISVLSI) (2017)
  * [17] Khan, N., Silitonga, A., Pachideh, B., Nitzsche, S., Becker, J.: Secure local configuration of intellectual property without a trusted third party. In: Applied Reconfigurable Computing (2019)
  * [18] Koteshwara, S., Kim, C.H., Parhi, K.K.: Key-based dynamic functional obfuscation of integrated circuits using sequentially triggered mode-based design. IEEE Transactions on Information Forensics and Security (2018)
  * [19] Kömürcü, G., Savas, E.: An efficient hardware implementation of the tate pairing in characteristic three. In: ICONS (2008)
  * [20] Maes, R., Schellekens, D., Verbauwhede, I.: A pay-per-use licensing scheme for hardware ip cores in recent sram-based fpgas. IEEE Transactions on Information Forensics and Security (2012)
  * [21] Miller, V.S.: Use of elliptic curves in cryptography. In: CRYPTO (1985)
  * [22] Saha, D., Sur-Kolay, S.: FPGA-Based IP and SoC Security. Springer International Publishing (2017)
  * [23] Skhiri, R., Fresse, V., Jamont, J.P., Suffran, B., Malek, J., Margala, M.: From fpga to support cloud to cloud of fpga: State of the art. International Journal of Reconfigurable Computing (2019)
  * [24] Trimberger, S., Moore, J.: Fpga security: From features to capabilities to trusted systems. In: 2014 51st ACM/EDAC/IEEE Design Automation Conference (DAC) (2014)
  * [25] Turan, F., Verbauwhede, I.: Proxy re-encryption for accelerator confidentiality in fpga-accelerated cloud. Cryptology ePrint Archive (2020)
  * [26] Turan, F., Verbauwhede, I.: Trust in fpga-accelerated cloud computing. ACM Comput. Surv. (2021)
  * [27] Vliegen, J., Mentcns, N., Verbauwhede, I.: A single-chip solution for the secure remote configuration of fpgas using bitstream compression. In: ReConFig (2013)
  * [28] Zeitouni, S., Dessouky, G., Sadeghi, A.R.: Sok: On the security challenges and risks of multi-tenant fpgas in the cloud. In: CoRR (2020)
  * [29] Zeitouni, S., Vliegen, J., Frassetto, T., Koch, D., Sadeghi, A.R., Mentens, N.: Trusted configuration in cloud fpgas. In: 2021 IEEE 29th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM) (2021)