Florent Moriconi

Eurecom Amadeus

Axel Ilmari Neergaard

Eurecom Cujo

Ai Lucas Georget

Samuel Aubertin

Eurecom Aurélien

Francillon Eurecom

Reflections on Trusting Docker: Invisible Malware in Continuous Integration Systems

Continuous integration (CI) is a widely adopted methodology for supporting software development. It provides automated generation of artifacts (e.g., binaries, container images) which are then deployed in production. However, to which extent should you trust the generated artifacts even if the source code is clean of malicious code? Revisiting the famous compiler backdoor from Ken Thompson, we show that a container-based CI system can be compromised without leaving any trace in the source code. Therefore, detecting such malware is challenging or even impossible with common practices such as peer review or static code analysis. We detail multiple ways to do the initial infection process. Then, we show how to persist during CI system updates, allowing long-term compromise. We detail possible malicious attack payloads such as sensitive data extraction or backdooring production software. We show that infected CI systems can be remotely controlled using covert channels to update attack payload or adapt malware to mitigation strategies. Finally, we propose a proof of concept implementation tested on GitLab CI and applicable to major CI providers.

I. INTRODUCTION

DevOps' mindset encourages the use of Continuous Integration (CI) to quickly alert developers when a code change does not meet quality requirements. In practice, a CI system runs a set of checks (i.e., a CI build) on code changes. Quality checks can be manual (e.g., peer-review) or automated. In practice, automated steps of a CI build are often composed of a compilation, static code analysis (e.g., code linting tools, vulnerability scanners), binary scanning, tests (e.g., unit-testing, end-to-end testing, regression testing, functional validation), and deployment of artifacts (e.g., binaries, Docker images, tarball archives, pip packages) to a remote registry. Furthermore, CI build servers aim to provide a more controlled environment than developers' laptops to increase security. The CI is orchestrated by a CI orchestrator, notable examples include Jenkins, GitHub Actions, and Travis CI. Nowadays, CI orchestrators make extensive use of containers. Indeed, containers allow identical environments between a developer laptop, CI build environment, and the production servers. When a CI build starts (e.g., on code change), the orchestrator starts a new container. The container is based on a container image called the CI build image. This image is generally common to all builds of a specific family (e.g., Javabased software, Python-based software). It must contain all the tools required to perform the CI steps: compilers, linters, code analyzers, test frameworks, company-specific tools, etc. Therefore, it is common for this image to be customized by the developers to include the necessary tools. This means that the construction of the CI image is considered likewise another software and therefore, it is often built using the CI system itself. As a consequence, CI systems are considered selfhosted architectures [START_REF] Wikipedia | Self-hosting (compilers)[END_REF]. Thompson [START_REF] Thompson | Reflections on trusting trust[END_REF] showed that self-hosted architectures raise new questions about security. This is, in particular, the case with a C compiler written in C. Thompson shows that if malware is present in the compiler and re-injects itself when the compiler is built, then detecting such malware is challenging. Therefore, to what extent should you trust that your system is free of malware? In this paper, we show that the same reasoning can be applied to continuous integration systems. In particular, we make the following contributions:

• We show that a CI system can backdoor production software without leaving any trace in the source code repository • We show that malware can persist on updates in a selfhosted CI system • We show that malware in a CI system can be updated using hidden channels • We implement a proof of concept implementation targeting Docker-based CI systems The paper is structured as follows. In Section II, we present literature on trusting software systems and CI malware. In Section III, we show how to achieve a CI malware without any trace in the source code. In Section IV, we detail a proof of concept implementation targeting Docker. In Section V, we explore the limits of the approach and mitigation strategies. In Section VI, we conclude and show future paths of improvement.

II. RELATED WORK

Our work is based on the question raised by Thompson [START_REF] Thompson | Reflections on trusting trust[END_REF] regarding self-hosted architectures. Thompson showed that one should not trust any program which was not written by oneself directly in machine code. He described how self-replicating programs, called quines [START_REF]Quine Programs[END_REF], can learn and perpetuate knowledge over time. When applied to C compilers, he showed that it can be leveraged to backdoor the UNIX "login" command (e.g., add an attacker-controller password). Indeed, quines can learn and perpetuate knowledge without any trace in the source code. Figure 1 teach the compiler that \v is equal to ASCII character 11. Then, even after removing the rule from the source code, \v will be modified to ASCII character 11 as the rule is now part of the compiler. Furthermore, the rule will be persistent when the compiler is compiled again (e.g., compiler update). Gratzer et al. [START_REF] Gratzer | Alien vs. quine, the vanishing circuit and other tales from the industry's crypt[END_REF] show that knowledge acquired by quines is difficult to detect and remove. Compilers are an interesting target because of their ability to alter source code just before compilation. Bauer et al. [START_REF] Scott | Deniable backdoors using compiler bugs[END_REF] took advantage of compiler bugs in GCC to create a backdoor. Furthermore, two real-world attacks leveraged this concept. In 2009, the Win32.Induc.A virus [START_REF]Virus:w32/induc.a[END_REF] infected Delphi compilers to add malicious code to applications built using the compiler. In 2015, Xcodeghost [START_REF] Xiao | Novel malware xcodeghost modifies xcode, infects apple ios apps and hits app store[END_REF] was one of the most successful attacks on the Apple App Store. It consisted of a modified Xcode compiler that makes the applications being spied.

Attacks against CI systems leverage their dependencies to a large number of components such as code dependencies or tooling (e.g., linters). Improper configuration of CI [START_REF] Koishybayev | Characterizing the security of github CI workflows[END_REF] can lead to vulnerabilities [START_REF] Labs | Your jenkins belongs to us now: Abusing continuous integration systems[END_REF], [START_REF] Quist | The anatomy of an attack against a cloud supply pipeline[END_REF]. Backdoors [START_REF] Thomas | Backdoors: Definition, deniability and detection[END_REF] often refer to a long-term compromise of targeted systems. Therefore, the malicious code should persist on updates. There are different ways to get initial access to the system in CI environments.

Common vulnerabilities are listed by the OWASP foundation [START_REF] Owasp | Owasp top 10 ci/cd security risks[END_REF]. Notable examples include hypocrite commits [START_REF] Wu | On the feasibility of stealthily introducing vulnerabilities in open-source software via hypocrite commits[END_REF], dependency confusion [START_REF] Birsan | Dependency confusion: How i hacked into apple, microsoft and dozens of other companies[END_REF], or supply chain attacks (e.g., attacks on upstream packages). OSC&R [START_REF] Ltd | Open software supply chain attack reference (osc&r)[END_REF] framework describes common techniques for supply chain attacks, such as compromising legitimate artifacts or publishing and advertising malicious ones. Williams [START_REF] Williams | Trusting trust: Humans in the software supply chain loop[END_REF] shows that attackers tend to focus on popular projects largely used by the developer's community even if they are often better protected. In addition, malicious code can come directly from project maintainers [START_REF] Arstechnica | Sabotage: Code added to popular npm package wiped files in russia and belarus[END_REF]. Therefore, malware in CI can come from malicious code in dependency repository [START_REF] Popov | Update on git.php.net incident[END_REF] or exploits against pipelines [START_REF] Welton | Exploiting continuous integration (ci) and automated build systems[END_REF]. In addition, bypassing auto-merge rules [START_REF] Ryotak | Remote code execution in homebrew by compromising the official cask repository[END_REF] or required reviews [START_REF] Gil | Bypassing required reviews using github actions[END_REF] can help to merge malicious code to main branch.

Docker is widely used as it provides consistent execution environment in different systems. However, it raises new questions about security [START_REF] Martin | Docker ecosystemvulnerability analysis[END_REF], [START_REF] Bui | Analysis of docker security[END_REF], [START_REF] Combe | To docker or not to docker: A security perspective[END_REF]. Indeed, Docker containers share the same kernel as the host system. Furthermore, container images can be made by the community. While images can be analysed to detect malicious or vulnerable code, analysis often rely on database of malicious content. This does not allow the detection of unknown (zero-day) attacks. Therefore, the use of containers for CI could open up new security vulnerabilities.

Wheeler [START_REF] Wheeler | Fully countering trusting trust through diverse doublecompiling[END_REF] proposes a countermeasure to detect attacks described by Thompson through diverse double-compiling. It can be combined with other emerging solutions such as bootstrappable [START_REF] Builds | Bootstrappable Builds[END_REF] and reproducible [START_REF] Builds | Reproducible Builds[END_REF] builds (i.e., methods ensuring consistency between binaries and source codes) to improve trust in software [START_REF] Skrimstad | Improving trust in software through diverse doublecompiling and reproducible builds[END_REF]. Regarding supply chain attacks, attempts have been made to detect and mitigate them, such as forensic [START_REF] Ohm | Towards detection of software supply chain attacks by forensic artifacts[END_REF] or safeguard levels [START_REF] Slsa | Supply chain Levels for Software Artifacts[END_REF] artifacts. Regarding Docker, Petazzoni [START_REF] Petazzoni | Using docker-in-docker for your ci or testing environment? think twice[END_REF] warned about using Docker-in-Docker as it requires privileged container which makes it easier to attack the host system. Zero Trust Container Architecture [START_REF] Leahy | Zero trust container architecture (ztca): A framework for applying zero trust principals to docker containers[END_REF] encourages to always consider the code within the container as potentially malicious, asking to higher level of security. In the following section we describe our approach to target container-based CI systems.

III. OUR APPROACH

We propose a new approach to compromise continuous integration systems. The approach does not leave any traces in source code repositories. Therefore, the compromise cannot be detected by auditing code repositories, a widely used way to assess software security. Figure 2 shows a general overview of the approach. Our approach requires that at least one component of the CI system use a self-hosted architecture. We detail in the following section how we identify the best location for the malware. Then we detail the self-injection process to persist on CI updates. We present possible strategies for the initial infection process. Finally, we present a few possible attack payloads and how the malware can be remotely controlled using hidden channels.

A. Self-hosted architecture

We propose malware that does not leave any trace in source code repositories. Therefore, this excludes storing the malicious code in the CI system code repository. Furthermore, the malicious code must be stored in a component (e.g., Docker client, Docker daemon, shell, test framework) that is in a self-hosted architecture. Without self-hosted architecture, the malware would be overwritten by a clean component version (i.e., build from repository source code free of malware) on CI updates. Custom build images are commonly used to avoid reinstalling all the necessary tools (e.g., linters) each time the CI build is started, leading to a self-hosted architecture. As CI updates might happen often (e.g., new features, bug fixes, upgrade tool versions), targeting a component in a self-hosted architecture is required for long-term compromise. Figure 3 shows the workflow for building the CI build image. It shows up that the CI build image is built from the CI build container. Furthermore, the CI build container is created from the CI build image. Therefore, this is a self-hosted architecture In green, the source code is free of malware. In red, the infected containers and images. (A) refers to initial infection using hypocrite commits, and (B) refers to initial infection using an in-container vulnerability (e.g., dependency confusion). for components inside the build container. However, some components might be external to the CI container. Figure 4 shows different strategies for building Docker images in a continuous integration build container. When building a Docker image using Docker client (1) or in-container tool (2) such as Kaniko [START_REF] Google | kaniko -build images in kubernetes[END_REF], this is a self-hosted architecture. However, this is not a self-hosted architecture if the building is done by an external component such as host Docker daemon, Docker-in-Docker, or distributed system. In practice, Docker-in-Docker is a very common architecture pattern for CI as it helps to target a full containerized architecture. Using the host Docker daemon is a bad practice as it gives root access to the host system from a CI build container [START_REF] Tenable | Ensure only trusted users are allowed to control docker daemon[END_REF]. External systems (e.g., distributed build systems) are tailored for specific needs, such as very large build volumes, and are rarely used. Therefore, to support Docker-in-Docker (dind) architecture, we must implement the malware in a self-hosted component. It means targeting software that is stored in the CI build container. This is the case with the Docker client and in-container build tools such as Kaniko. Docker client is a Command Line Interface (CLI) tool that interacts with the Docker daemon, whether the daemon is in another container (dind), on the host system over a bind mount, or in an external system. Therefore, we choose to implement the malware in the Docker client instead of the Docker daemon. The same approach can be applied to Kaniko. However, as the Docker client is more widely used than Kaniko, we focus on the Docker client. Indeed, the Docker client interacts with the Docker daemon to send build context (i.e., Dockerfile, source files, parameters) to the daemon. In the following section, we detail how the Docker client can re-inject the malware when building the CI image that contains the Docker client.

Container image registry

B. Reproduction mechanism

When building a Docker image in the CI, the malware must be able to re-inject itself when a new CI build image is built: this is the self-reproduction mechanism. As presented in the previous section, we choose to hide the malware in the Docker client as it is present in the CI build image. It can be installed manually by developers (i.e., through a package manager or rarely by compilation) or taken from a base Docker image (e.g., docker:latest image). The Docker client should detect if the image being built is the CI build image or an image of interest for the attack payload. We detail in Section III-D potential attack payload actions. The Docker client might rely on the image name or build context heuristics to identify the image being built. As the Docker client has access to the build context, it can check for the presence of specific files in the build context (i.e., source code). For instance, it might check for the presence of the program /usr/bin/docker. We can re-inject the malware in any Docker image containing the client. However, to reduce the detection risk, we would rather try to re-inject the malware only when the CI image is built. For this purpose, we rely on image names and other rules, such as filenames that only appear in CI build images (e.g., test framework, Docker client). Before being able to selfreproduce, an initial infection must be performed.

C. Initial infection

The initial infection requires modifying the CI build image. Executing arbitrary code can accomplish this during image build or by directly altering the CI image in the registry. We detail below different strategies that internal or external attackers can apply. Therefore, our approach does not require a complicit actor (e.g., a company employee). Initial infection should only be done once, then, self-reproduction will ensure the malware will stay in the CI systems even on updates.

a) Malicious commit: The most straightforward method to execute attacker-controlled code during CI image build is to insert malicious code in the source code repository that defines the CI system. Qiushi et al. [START_REF] Wu | On the feasibility of stealthily introducing vulnerabilities in open-source software via hypocrite commits[END_REF] show that patch proposals injecting new vulnerabilities can be accepted in large open-source software projects like the Linux kernel. Therefore, the same method can be considered in a corporate environment. However, directly committing malicious code to the repository might be challenging when enforcing peer review and code scanning. To reduce the risk of detection, malicious code can be hidden by proposing a code change that looks legitimate (e.g., adding a new code linter in CI) and relies on a remote compromised package. However, the malicious commits approach requires access to a code management system (i.e., internal network access, credentials), which might be challenging for an external attacker. Another option is to leverage a vulnerability in dependencies management.

b) Compromised dependency: Builds often rely on a large number of dependencies. These dependencies can be internal to the company or public (e.g., open-source). Public dependencies can be leveraged to execute malicious code without committing to the target repository source code. Indeed, dependency confusion [START_REF] Birsan | Dependency confusion: How i hacked into apple, microsoft and dozens of other companies[END_REF] allows running attacker-controlled code in a continuous integration build server. The approach leverages how package managers (e.g., pip, npm) handle multiple registries. By default, they look up all configured registries and select the package with the highest version. Furthermore, public registries are commonly enabled by default (e.g., PyPI for Python pip). Therefore, creating a package on a public registry with the same name as an internal package and a higher version leads to dependency confusion. JFrog Artifactory, a widely used software to host internal artifacts, was vulnerable to dependency confusion. While attempts [START_REF] Sadogursky | Going beyond exclude patterns: Safe repositories with priority resolution[END_REF], [START_REF]snync[END_REF] have been made to mitigate these attacks, they are difficult to deploy at scale (e.g., not backward-compatible). Therefore, dependency confusion is still applicable to a wide range of systems.

c) Image registry compromising: Another way to compromise a CI image is to directly alter the image in the registry. Every CI build runs with a user that has privileges. For the build to succeed, these privileges are required: pull source code, download dependencies, or push artifacts. However, a poorly configured CI system might allow CI users to access or modify resources out of the scope of the current build. For instance, the CI users might have full read/write access to the container image registry, allowing any build to alter any stored image. This can happen when a unique user is shared across builds, or privileges are assigned to the CI server (e.g., EC2 IAM policy [START_REF] Aws | Iam roles for amazon ec2[END_REF], IP-based permission). Credentials might be wrongly populated [START_REF] Hodne | Security advisory: Encrypted environment variables[END_REF] to pull requests (PRs). Furthermore, opening PRs is often allowed for a large group of users. This might lead to the compromise of registry credentials, allowing manipulation of stored images.

D. Payload

Malware has a payload, i.e., a part of code that can take action. For malware targeting desktops, the payload often allows monitoring of the user: recording keyboard keys, listening to ambient sound, copying files, etc. In the context of a CI build environment, malware can access and modify sensitive data. Indeed, CI is often used to build artifacts that will be deployed to production. It aims to provide a more secure solution than developers' laptops. An attack payload might record and exfiltrate sensitive data such as environment variables or program source codes. Furthermore, the payload can alter the source code before compilation. In practice, it might create vulnerabilities in production software, such as authentication bypass. Finally, the payload can consist of network analysis and lateral movement over the network. Indeed, CI servers are often in the internal network perimeter. The attack's payload depends on the attacker's motivation and can therefore change over time. To this aim, we present strategies for remotely updating the malware in the following section.

E. Command & Control

After initial infection, malware might require to be updated. Indeed, target programs evolve (e.g., new code), or new security systems can be deployed. To this end, we developed a methodology for Command and Control (C&C) for the malware. C&C aims to be less detectable than reusing the initial infection workflow. In the context of a CI server, downloading packages from public registries (e.g., PyPI, npm) is common. Therefore, we can leverage this property to C&C the malware. By uploading a package to a public registry that the malware will download, we can C&C the malware. To further reduce the risk of being detected, the package should look like a standard package (e.g., code linter). However, some files inside the package will contain hidden material using steganography. Therefore, detecting that downloaded packages contain malicious code will be challenging. Other notable options for C&C include DNS tunneling [START_REF] Van Leijenhorst | On the viability and performance of dns tunneling[END_REF] or git-based tunneling. Encrypted files in git (e.g., SOPS [START_REF] Mozilla | Sops: Secrets operations[END_REF]) are widely used to securely store and share secrets required for software development. However, they create a blind spot for code scanners as they do not have encryption keys. This can be leveraged to hide malicious code behind encryption. Encrypted files will be decrypted by malware in the CI to update themselves. In practice, C&C will highly depend on the victim's infrastructure and security mechanisms. The next section details how we created a proof of concept implementation targeting Dockerbased continuous integration systems.

IV. IMPLEMENTATION

To demonstrate practical self-replicating and invisible malware in CI systems, we wrote a proof of concept implementa-tion targeting the Docker client [START_REF] Docker | Docker CLI[END_REF]. The latest version of the artifact is available at https://doi.org/10.5281/zenodo.7777331.

Docker Engine follows a client-server architecture consisting of a client communicating with a Docker daemon, acting as the server, using the HTTP or HTTPS protocol over TCP or a socket. The daemon creates and manages Docker objects, such as images and containers, whereas the client sends commands to the daemon and shows output (e.g., logs) to the user. When the client instructs the daemon to build a new image, the client sends a file consisting of build commands to assemble an image (referred to as a "Dockerfile"), along with any other required files (referred to as "context"). As detailed in Section III-A, we target the Docker client.

A. Bootstrapping

In the context of CI systems, the Docker client runs within the CI container: this is a self-hosted architecture. This makes it an apt target for the creation of self-replicating malware; if the client rebuilds itself, then it can be patched with a selfreplicating procedure like Thompson's [START_REF] Thompson | Reflections on trusting trust[END_REF]. Patching the client requires a bootstrapping [START_REF] Wikipedia | Bootstrapping[END_REF] phase before the initial infection of any CI system. The bootstrapping phase is performed by a custom script that produces a Dockerfile containing build commands to produce a client capable of self-replication.

a) Achieving self-replication: To achieve self-replication, two separate files are needed: (1) a Dockerfile with build commands to compile a Docker client (referred to as the "genesis Dockerfile" to avoid confusion), and (2) a patch of the Docker client source code. The build commands in the genesis Dockerfile must contain all required material to build a Docker client. The patch of the Docker client source code must include a procedure that detects when a target Dockerfile sent to the daemon (1) uses a base image containing a Docker client or (2) when a Docker client is assembled from scratch. It is noteworthy that the original (i.e., non-malicious) Docker client can come from the Docker base image, from package manager (e.g., apt), or from source. When the procedure detects one of these aforementioned scenarios, it applies the Docker client patch to the client version compiled in the build commands of the genesis Dockerfile. Afterwards, the procedure must replace the build commands in the target Dockerfile corresponding to the Docker client (base image or assembly) with the commands from the genesis Dockerfile. This procedure is based on the self-replication logic of a quine [START_REF]Quine Programs[END_REF]. We choose to compile the malicious Docker client in the build container to avoid fetching a malicious docker client over the network (that could be detected by intrusion detection systems). However, it is also possible to fetch the malicious client from a remote registry to avoid the the complexity of compiling it during initial infection or self-reproduction.

b) Performing bootstrapping: The custom script that performs bootstrapping produces a Dockerfile with selfreplicating logic based on the files introduced in the previous paragraph. The CI can be considered infected once this Dockerfile is used to assemble a CI image.Every rebuild of a similar image will then re-inject the self-replicating client patch. As illustrated in Figure 6, the custom script performs the following steps to create the aforementioned Dockerfile:

1) Insert the original genesis Dockerfile as a payload within the client patch. 2) Insert this client patch as a payload into itself.

3) Insert this final patch version as a payload into the original genesis Dockerfile. When this Dockerfile is used in real CI systems, the client patch in the payload will be used to compile the next Docker client. This new client will then have all the necessary material to rebuild itself by performing steps 1 and 2.Combined with the steps outlined in the previous paragraph, we have a fully self-contained and self-replicating version of the original Docker client. Thus, when a CI image is built using this new client, the CI image will be reinfected.

B. Initial infection

Initial infection is the first time our implementation is injected into a CI system. We tested our approach against a GitLab instance along with Docker-based GitLab runner. The initial infection is done in 2 steps: (a) altering a target Dockerfile and (b) assembling a CI image from the Dockerfile in the CI.

a) Altering a Dockerfile: The first step of the initial infection is to alter a target Dockerfile. A target Dockerfile is any Dockerfile that would result in the build of a CI image. The alteration includes modifying the target Dockerfile by replacing any base image mentioning or creating a Docker client with the build commands from a bootstrapped Dockerfile. This corresponds to (A) in Figure 2. This step can be achieved by any approach mentioned in Section III-C. Any approach that injects the build commands from a bootstrapped Dockerfile will result in the build of an infected CI image.

b) Assembling the CI image: Once the build commands are injected into a target Dockerfile, a new CI image has to be assembled based on the Dockerfile. In the initial infection, a clean CI container will assemble the new, malicious CI image corresponding to (B) in Figure 2. The very first build of the malicious CI image may be detected, as the target Dockerfile must contain the build commands from the bootstrapped Dockerfile. Additionally, the clean CI image will report all build commands performed in the image build as logs. This is the default behavior of Docker clients, as the logs support root cause analysis on failure. Hence, the initial infection may be revealed unless the target Dockerfile alteration is removed and logs from the clean CI container are concealed.

c) Future builds of the CI image: Once the initial infection has been successfully performed and the malicious CI image exists in the CI system, any consecutive build of CI images will result in malicious CI images. Thanks to the selfreplicating design of the Docker client patch, assembling a CI image will always result in a malicious image, regardless of whether the incoming Dockerfile includes the bootstrapping steps. This eliminates the need for altering a target Dockerfile anew; no changes to a target Dockerfile are required and do not need to exist in source code or in code repositories. The Docker client patch is designed to mask any output corresponding to build commands taken from the bootstrapped Dockerfile. Thus, the malicious CI container will not output any steps taken in self-replication, minimizing the chance of detection.

C. Attacking target software

The Docker client patch introduced in Section IV-A includes, in addition to its self-replicating code, any extraneous payload, such as malware. As this payload is packaged with the malicious CI image, it can perform any type of action that the CI container is authorized to perform. Moreover, as the CI container may be used to build other software, the payload can be targeted toward this build step. This gives a potential malicious actor a broad attack surface towards any software.

To test this capability, a custom attack was created for a toy project. The toy project is a C program that checks for credentials provided by a user, granting access if the credentials are correct. Moreover, the project is a compiled program and runs within a Docker container. The compilation step is performed as the project image is assembled. The custom attack targets this compilation step during image build.

When the Docker client within the malicious CI image recognizes that an image for this toy project is being assembled, it modifies the compilation build command. The modification instructs the Docker daemon to first replace code in the toy project, and then compile it, similar to what Figure 5 depicts. The replacement disables the credentials correctness check in the toy project, granting access upon any input. This capability is enabled by the client being allowed to read the Dockerfile and context of the toy project. In this case, the client recognizes the toy project by reading the context tags provided by a user.

D. Challenges

Many challenges were faced during the implementation of our proof-of-concept. Challenges were related to the design of the malware, constraints in tooling, and designing concealment of the initial infection, among others. a) Self-replication: Conceptualizing self-replication in the context of Docker is the first challenge of the implementation. Whereas the self-replication presented in [START_REF] Thompson | Reflections on trusting trust[END_REF] only requires the compiler source code to be changed, infecting a CI system requires modifying a Dockerfile and patching the Docker client source code. As Figure 6 illustrates, the Dockerfile and the client patch contain multiple payload levels. Each level is required to achieve self-replication; every level is required such that the client patch can behave as a quine, outputting its own source code dynamically and re-injecting the output into a CI image.

b) Payload encoding: Dockerfiles have a custom domain-specific language for building commands [START_REF] Docker | Dockerfile Reference[END_REF]. The RUN command executes listed arguments in a shell. When bootstrapping the genesis Dockerfile in Section IV-A, the Docker client patch is inserted into the genesis Dockerfile as a payload. The payload is used to modify the source code of the Docker client before compiling it, where the client is written in the Go programming language [START_REF] Docker | Docker CLI[END_REF]. This modification step uses both a RUN command and the client patch. This may result in a clash in syntax as both shell and Go syntax may have overlaps (such as the escape character \ for strings). To overcome this issue and any other potential syntax clashes, all payloads are base64 encoded before any insertion step in Figure 6. c) Dockerfile line length: Lines in Dockerfiles are restricted to 65535 characters, restricting the length of build commands. This length restriction was discovered empirically. As the bootstrapped Docker client patch exceeds 60000 characters, it will exceed the line length restriction once the payload is base64 encoded. All payloads were compressed with Gzip to overcome this restriction before being base64 encoded. As an additional side-effect, the compression aid in minimizing the footprint of the malware. d) Log filtering: Another challenge in the implementation was the masking of output logs. As the daemon executes build commands, they are logged with a prefix denoting the command's execution number. The logs are produced in the following manner, assuming 3 commands:

Step (1/3) <output of command1>

Step (2/3) <output of command2>

Step (3/3) <output of command3> Build commands injected from the bootstrapped Dockerfile would be logged along with commands from the target Dockerfile. This poses a challenge in achieving invisibility as logs leave a visible trace. Although the daemon produces the logs, they are outputted by the client. Overcoming this challenge thus required the custom client to parse received logs, and to deduce which build commands to mask. For this purpose, we created a procedure for parsing the infected target Dockerfile before passing it to the daemon. The procedure counts the number of commands to be executed, then subtracts the number of commands passed by the bootstrapped Dockerfile. Before outputting the final logs, each log line containing the Step prefix was manipulated to show a subtracted amount. Re-using the example above and assuming that the line containing <command2> is part of the bootstrapped Dockerfile, the procedure produced the following output:

Step (1/2) <output of command1>

Step (2/2) <output of command3>

This enhanced the invisibility of self-replication and lowered the probability of discovery.

e) Custom attacks: Attacks must be tailored for the target environment before attaching them as payloads to the source code in (A) of Figure 2. This requires pre-existing knowledge of the target environment to infect target software successfully. This may pose a challenge to an attacker without prior knowledge of the said environment, as an infection may fail and potentially reveal itself. An attacker may consider targeting a long-running container by inserting a backdoor. This would allow the attacker to enter the target environment and explore it further before creating a targeted attack. However, this would still challenge the attacker to know which container to target with a backdoor, requiring prior knowledge of the environment. Nevertheless, implementing a C&C system would allow the attacker to update the malicious content incrementally.

E. Limitations

Our proof of concept has a few limitations that might be resolved with enough engineering effort. We detect a CI image by checking the image name. However, the image name can be changed by developers. Detecting CI images based on build context would be more resilient. When re-injecting, the Docker client is compiled. This takes time, which increases the risk of being detected even if the logs are hidden. The patch for the Docker client targets a specific version of the client. While the code we rely on for the patch should be quite stable, we do not handle Docker client updates.

The proof of concept does not have any update mechanism in place. Thus, any change in the target environment may potentially reveal the malware or self-replication. Nevertheless, as outlined in Section III-E, command and control can be implemented through different means, such as steganography.

No fallback mechanism exists in case of errors caused by the proof of concept. This may prevent the build of CI images or target software, which is detectable by users. A potential mitigation strategy would be to notify a command and control server and request updates. Another strategy would be to revert any attempt at infection to escape detection.

V. DISCUSSION

Our approach requires to have a self-hosted architecture to provide a long-term compromise. However, self-hosted architecture can be avoided. A different CI system can be used to build CI images or manually built on developers' laptops. Furthermore, CI containers can use images built by other actors (e.g., community images). We implement the malware in the Docker client code stored in CI build image. Rkhunter [START_REF]The rootkit hunter project[END_REF] is an open-source tool that scans for rootkits by comparing SHA-1 hashes of local files with an online database of wellknown software. In the context of this work, deploying such a tool for checking binary file integrity in CI images might help to detect such compromise. Similarly, Prisma Cloud [START_REF] Networks | Prisma cloud[END_REF] provides Docker image scanning capabilities to detect vulnerable software and common misconfiguration. They rely on a database of hashes of malicious software. Custom rules can be developed to detect CI image manipulation. Docker Content Trust [START_REF] Docker | Content trust in docker[END_REF] (DCT) provides a signature mechanism to authenticate the author of the image and ensure that the image has not been tampered with. However, as images are built and signed by CI, DCT does not help to detect image manipulation by the CI. Indeed, DCT was designed to detect attacks that alter images in the Docker registry. We tested our attack on a GitLab with a self-hosted runner. However, our approach works on major CI providers as far as the self-hosted condition is verified. GitHub Actions, Jenkins, and Travis allow the use of custom images for building containers and do not prevent the use of CI images in the CI itself, leading to self-hosted architecture. Therefore, they are vulnerable too.

VI. CONCLUSION

We proposed an effective method for long-term compromise of continuous integration systems. Initial infection can be done remotely by leveraging vulnerabilities such as dependency confusion. After the initial infection, no traces are present in the source code repository, greatly reducing the risk of being detected. In addition, C&C can be done through covert channels using public package registries, which allows the attack payload to be updated with a very low risk of detection. Therefore, our approach raises new questions about responding to security incidents involving continuous integration systems: how do we know the system has not been compromised without leaving any trace in the source code?

Fig. 1 .

 1 Fig.1. Illustration of the learning process and perpetuation of knowledge in a compiler. After learning (step 2), compiler is able to apply the knowledge without explicit rule (step 3).

Fig. 2 .

 2 Fig.2. Overview of initial infection and after infection modes (self-reproduction and payload). In green, the source code is free of malware. In red, the infected containers and images. (A) refers to initial infection using hypocrite commits, and (B) refers to initial infection using an in-container vulnerability (e.g., dependency confusion).

Fig. 4 .

 4 Fig. 4. Overview of different strategies for building Docker images from CI container. Docker client (1) or in-container build tool (2), such as Kaniko, can be used. The Docker client connects either to the host Docker daemon (a), a daemon in another container, i.e., Docker-in-Docker (b), or an external daemon over the network (c).

Fig. 6 .

 6 Fig. 6. Illustration of bootstrapping flow. Green represents a step taken, while red represents a payload within a program. The leftmost box consists of a genesis Dockerfile and patches client code. Step 1 inserts the genesis Dockerfile into the patched client code as a payload. In step 2, the patched client code is inserted into itself as a payload. Finally, the patched code is inserted into the genesis Dockerfile in step 3. The final Dockerfile and client code versions now contain enough information to perform self-replication.

  illustrates this property. The first step is to

	Input	Rules	Knowledge	Output
	'\v'	X	X	'\v'
	'\v'	'\v' == '11'	'\v' == '11'	'|'
	'\v'	X	'\v' == '11'	'|'

  Fig. 5. Overview of on-the-fly injection of malicious code during Docker build. In red, malicious code is inside the Docker client. Backdoor code is injected in the build context before sending it to the Docker daemon.

			Continuous integration server
	source software Target	Code linters	scanners Vulnerability Build container Docker build	Docker push	image target software Backdoored
		1) Read Docker build context from filesystem
		2) Send context to Docker daemon RUN sed -i s/deny/allow auth.c	add layer	Malware
			Docker CLI, i.e., /usr/bin/docker

ACKNOWLEDGEMENTS

This work has benefited from a government grant managed by the National Research Agency under France 2030 with reference "ANR-22-PECY-0007".


Igor Dias Da Silva

Yann Busnel

Christelle Caillouet

Optimisation de plan de vol de drones autonomes pour une recharge rapide de capteurs

Keywords: Drones, Optimisation, Recharge énergétique, Internet des objets

Nous proposons une solution en deux étapes pour déterminer des trajectoires quasi-optimal de véhicules aériens sans pilote (UAV), ou drones, afin de recharger rapidement un réseau de capteurs au sol, augmentant ainsi la durée de vie de celui-ci. Nous nous concentrons sur une solution de recharge sans fil par radiofréquence (RF), lequel permet notamment de pouvoir charger plusieurs capteurs en parallèle par un même drone. Cependant, il existe une forte déperdition d'énergie lorsque plusieurs drones chargent le même capteur simultanément. Nous optimisons donc le plan de vol de la flotte de drones afin de minimiser le temps nécessaire pour charger tous les capteurs, tout en évitant cette déperdition.

Introduction

The application of sensor networks has grown significantly in the fields of industry, military, home automation, ecology, precision agriculture, disaster management, etc. The majority of the aforementioned use cases require the implementation of sensor systems over long periods of time. Optimising the lifetime of each sensor is a key element in the deployment of these wireless systems and thus, we are interested in recharging the sensors' batteries to improve the lifetime of the systems and their usability.

We focus on a wireless Radio Frequency (RF) power harvesting solution. The unquestionable advantages of these solutions are flexibility, adaptability, and automation. This allows us to use mobile vehicles, such as Unmanned Aerial Vehicles (UAVs), to visit the sensors regularly to recharge them and collect their data. The objective is to define automatic and autonomous flight plans for this fleet of drones to power up energyconstrained sensor nodes.

In this work, we present a short version of the outcomes presented in [START_REF] Da Silva | Trajectory optimization for fast sensor energy replenishment using uavs as rf sources[END_REF]. We propose a two-step optimization framework to determine the UAVs' trajectories to quickly replenish the sensor energy. Given the sensors' positions, their energy requirements, and the number of available UAVs, we first derive a Mixed Integer Linear Program (MILP) to optimise both the placement of the UAVs and the associated hovering times in order to minimise the overall charging time (excluding moving flight time). Then, in the second step, we propose a greedy algorithm to schedule the flight plans while avoiding conflicts that can lead to less efficient loads. We take advantage of the fact that one UAV can charge multiple sensors simultaneously but we avoid the efficiency loss that happens when multiple UAVs charge the same sensor at the same time [START_REF] Altinel | Energy harvesting from multiple rf sources in wireless fading channels[END_REF].The output is a set of UAV conflict-free trajectories fulfilling the positions computed by the MILP while minimizing the overall duration for recharging the whole system.

Two Step Framework

Our problem consists of determining the trajectories of a set U of UAVs, such that, by following these trajectories, all the ground sensors in a given set S will have their batteries charged. These trajectories are defined for each drone as (i) a list of positions the drone must visit and (ii) the corresponding amount of seconds the drone must remain in each position. The objective is to charge the sensors as fast as possible.

To solve this multi-constraints problem, the first step of our framework consists of a mixed integer linear program (MILP) that determines which positions the drones must visit and how long the drones should hover in these positions. The second step is to determine the order in which the positions should be visited, and avoid conflicts such as multiple drones visiting the same position at the same time.

Mixed integer linear program

The information of which positions the drones visit and for how long is modeled respectively by the binary variables y u p and the real variables t u p . These variables are defined for all available drones u ∈ U and for all possible positions p ∈ P, where P is the discrete set of positions the drones can visit in a 3D space and U is the set of available drones. The binary variables y u p describe whether a drone u should be deployed at position p or not. y u p is 1 if the drone u is deployed at position p ∈ P, 0 otherwise. And the real variables t u p describe for how many seconds the drone u remains in position p.

Our main goal is to charge the ground sensors, s ∈ S, where each sensor s has an amount of energy required E s . Therefore, the main constraint of the MILP ensures that the drones' positioning and the hovering times described by the variables y u p and t u p must allow the sensors to harvest enough energy to replenish their batteries. We use the energy model described in [START_REF] Zorbas | Assessing the cost of rf-power harvesting nodes in wireless sensor networks[END_REF] to compute how much energy a sensor can harvest from a drone u in a position p during t u p seconds. Then, we ensure that the total energy received by each sensor s ∈ S is equal or greater than the sensor's energy requirement E s .

Hence, a feasible solution to the MILP describes in which positions the UAVs must be deployed and for how long, while ensuring that all sensors are charged. The MILP's objective function is to minimize both the time the UAVs spend in the air charging the sensors and the number of positions they visit.

Wait-Time Scheduling Algorithm

The output of the previous linear model is a set of tasks, where a task k is given by a drone u k , a position p k , a duration t k in seconds and a set of sensors S k that are charged during the task's execution. Each drone can have multiple tasks to complete, and our goal here is to determine the order in which the drones complete their respective tasks without conflicts.

There is a conflict between two tasks k and k * if (i) they use the same drone (u k = u k * ), (ii) they use the same position (p k = p k * ), or (iii) they charge some common sensors at the same time (S k ∩ S k * ̸ = / 0) (to avoid the multi-charger constraints [START_REF] Altinel | Energy harvesting from multiple rf sources in wireless fading channels[END_REF]). A task is said to be conflict-free at a given moment if it has no conflict with any of the tasks being currently executed. We ignore possible collisions while the drones move.

Even if we ignored the possible conflicts between tasks, determining the fastest order of tasks for each drone is the same as solving the Traveling Salesman Problem (TSP) that is known to be NP-hard. We therefore present a greedy algorithm that assign the tasks in order to minimise the total time the drones have to wait hovering to avoid conflicts. More precisely, the algorithm runs as follows :

1. We order the tasks in increasing order of the wait-time (how long the UAV must wait until it can execute the task). If the task k is conflict-free, then the wait-time corresponds to the time of flight (ToF), that is, the necessary time for drone u k to reach p k from its previous position. However, if the task k is in conflict with some task k * being currently executed, then its wait-time is max(ToF, f k * ), where f k * is equal to the remaining duration before k * ending. In some cases, when k * uses the same drone as k, the wait-time is f k * + ToF, as the drone u k will only be able to move when k * is finished. 2. Once the tasks are ordered, if a task is conflict-free, we assign it immediately. This changes the waittime of the remaining tasks, and they must be reordered. If a task k is not conflict-free and u k is not executing any task, then u k moves to p k in advance so that it can execute k as soon as it becomes conflict-free.

An illustration of the wait-time algorithm is presented in Figure 1. The linear program has computed 12 tasks assigned to 4 drones to cover 40 sensors. The lines represent the time a drone spends flying, and the rectangles represent the period of execution of the tasks when the drones send RF signals to recharge the sensor batteries.

All drones start at the same location corresponding to a base station located at position (0, 0) in our experiments but our model can take into considerations multiple starting positions. The tasks are ordered following the wait-time algorithm. Task 4 has the shortest wait-time (at the beginning the wait-time is simply the time of flight), so it is the first one to be assigned. Now we must reorder the remaining tasks because their wait-time may have changed if they have a conflict with Task 4. For example, the wait-time for Task 7 is no longer its time of flight, but f 4 , the time remaining for Task 4 to finish. Tasks 0 and 11 once again have the same wait-time because they are both conflict-free and have the same time of flight. Once Task 0 is assigned, we reorder the tasks and, as the wait-time for Task 11 remains the same and the smaller one, it is then assigned to drone 3. The tasks are reordered once more, and, Task 8 is the one with the smallest wait-time since it only needs to wait for Task 0 to finish. Task 2 also needs to wait for Task 0 to finish, but since they use the same drone, it can only travel after Task 0 finishes, so its wait-time is larger than Task 8. The execution of the algorithm continues consecutively, until all tasks have been assigned and the chronogram shown in Figure 1 is obtained.

Results

We consider a 2-dimensional area of size 50m × 50m where sensors are randomly placed. We divide the area as a 5×5 grid with 5 possible altitudes, totaling 125 possible positions to deploy the drones. The number of sensors varies between 5 and 50 while the number of drones available to charge them varies from 3 to 10. Each sensor requires 150 mJ of energy.

The first step of our framework is the MILP determining the optimal positions that should be visited by the drones and for how long to recharge the battery of the sensors using RF-signals. As one can observe in Figure 2a, the more sensors to charge, the more positions the drones must visit. On the other hand, the more drones we have, the fewer positions they need to visit on average. Figure 2b depicts the average time a drone spends in the same position. With a higher density of sensors, each drone can charge more sensors at once, but it requires a higher altitude to provide more coverage, which increases the distance between the UAV and the sensors, and consequently increases the time required in each position to charge the sensors.

Given the results of the MILP, we then apply the wait-time algorithm presented in Section 2.2 to schedule the trajectory (e.g. order of tasks) for the drones in order to minimise the total time of the energy replenishment problem (including time of flight and waiting time due to conflict avoidance). We also proposed other scheduling algorithms such as the optimal, the TSP, the Time of Flight (ToF) and the Shortest/Longest Tasks First algorithms.

In the optimal algorithm we consider all possible permutations of tasks and, for each permutation, we assign the tasks accordingly. From all the possible schedulings we select the optimal one with the minimum total recharge time. As for the TSP algorithm, given the set of visited positions for each drone provided by the MILP, we compute the optimal TSP solution by brute-force. This solution gives us a lower bound for the global minimum time to recharge the sensors. However, this solution is not conflict-free, meaning that the computed trajectories can allow multiple simultaneous UAV chargers for a sensor, therefore limiting the efficiency of the harvesting system. The ToF algorithm is similar to the wait-time algorithm except that the tasks are ordered only by their time of flight in increasing order. Finally, in the Shortest/Longest Tasks First algorithms, we order the tasks by their duration in ascending/decreasing order. For each task, if it is conflict-free, we assign it immediately. Otherwise, the drone moves at the last moment to start charging as soon as possible (i.e. when it becomes conflict-free). Figure 2c compares the performance of the different algorithms. The figure illustrates how long it takes to charge all sensors by scheduling the tasks with each algorithm. As expected, we see that no greedy algorithm can charge the sensors as fast as the TSP because the TSP solution allows conflicts. But then, the wait-time algorithm outperforms all the other naive greedy approaches.

Out of the 2800 scenarios, we manage to solve the Optimal algorithm on 870 instances with less than 10 tasks because taking into consideration all possible tasks permutations consumes a lot of time. In these 870 scenarios, the optimal algorithm charges all sensors in 803.92 seconds on average. The wait-time algorithm takes on average only 3.28 % longer to charge the sensors than the optimal scheduling. The ToF algorithm takes 7.87 % longer on average, while the Longest Tasks First and Shortest Tasks First take 4.80% and 5.39% longer, respectively. In fact, we observed that all algorithms can reach the optimal solution in some instances. The wait-time algorithm reaches the optimal solution in 63.9 % of the instances. The ToF algorithm reaches the optimal solution in 59.54% of the instances, while the Longest Tasks First and Shortest Tasks First reach the optimal solution in 51.14 % and 47.01 % of the cases.

Conclusion

We presented a two-step framework for optimal energy replenishment of a set of sensors, using UAV as RF sources. We first solve a mixed integer linear program to determine the drones' placement in a 3D space such that it minimizes the time required to charge all ground sensors. Then, we proposed a wait-time heuristic to compute the order in which the drones should visit the deployment positions while avoiding conflicts and taking advantage of the parallelism between tasks. Avoiding these conflicts, such as multiple drones charging the same sensors simultaneously, ensure a higher energy harvesting efficiency. In the future, we would like to take the number of conflicts between tasks as a metric to be minimized in the MILP itself, to push for more parallelism which would allow us to benefit even more from a higher number of drones. The full work is presented in [START_REF] Da Silva | Trajectory optimization for fast sensor energy replenishment using uavs as rf sources[END_REF].

FIGURE 1 -

 1 FIGURE 1 -Example using the wait-time algorithm to schedule the tasks in a 5x5 grid with 40 sensors and 4 drones.

  The mean number of positions each drone must visit.

  The mean time each drone spends in the same position (tasks' mean duration).

  Total recharge time for all 2800 scenarios. Optimal cannot be depicted.

FIGURE 2 -

 2 FIGURE 2 -MILP and scheduling results


Tung Huu Dang

Claire Abadie

Audrey Chu

Mariarosa Cavallo

Adrien Khalili

Corentin Dabard

Erwan Bossavit

Huichen Zhang

Yoann Prado

Debora Pierucci

James K Utterback

Yanko Todorov

Carlo Sirtori

Julien Jaeck

Grégory Vincent

Angela Vasanelli

Baptiste Fix

Emmanuel Lhuillier

Bias reconfigurable photoresponse of infrared nanocrystal film integrated into a coupled Fabry-Perot resonator

Keywords: light-matter coupling, active photonics, reconfigurable response, infrared, nanocrystals

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Over recent years, significant efforts have been put forth to use colloidal nanocrystals (NCs) as building blocks for infrared optoelectronics. Certainly, the success achieved in the visible region, where NCs have reached a mass market as narrow emitting light down-converters, has motivated this effort. In the infrared, the prospect of bringing a cost disruption to a spectral region where detectors and sources are dramatically more expensive than their counterparts operating in the visible range has also spurred the interest in colloidal nanomaterials. Some clear successes have been obtained through the design and fabrication of components 1 such as on-chip integrated sensors [START_REF] Tang | Colloidal Quantum-Dots/Graphene/Silicon Dual-Channel Detection of Visible Light and Short-Wave Infrared[END_REF][START_REF] Zhu | Integrated Plasmonic Infrared Photodetector Based on Colloidal HgTe Quantum Dots[END_REF] , infrared cameras [START_REF] Gréboval | Photoconductive Focal Plane Array Based on HgTe Quantum Dots for Fast and Cost-Effective Short-Wave Infrared Imaging[END_REF][START_REF] Zhang | Wafer-Scale Fabrication of CMOS-Compatible Trapping-Mode Infrared Imagers with Colloidal Quantum Dots[END_REF][START_REF] Zhang | Direct Optical Lithography Enabled Multispectral Colloidal Quantum-Dot Imagers from Ultraviolet to Short-Wave Infrared[END_REF][START_REF] Zhang | Material Perspective on HgTe Nanocrystal-Based Short-Wave Infrared Focal Plane Arrays[END_REF] , spectrometer [START_REF] Grotevent | Integrated Photodetectors for Compact Fourier-Transform Waveguide Spectrometers[END_REF] , and LEDs [START_REF] Shen | Mid-Infrared HgTe Colloidal Quantum Dot LEDs[END_REF][START_REF] Qu | Electroluminescence from Nanocrystals above 2 Μm[END_REF] .

In addition, NCs lift the constraints of epitaxial growth. Therefore, although they still contain heavy metals (Pb and Hg mostly), low-cost/low-toxicity substrate materials can be used as opposed to epitaxially grown semiconductor thin films relying on materials such as GaAs or CdZnTe. Moreover, nanocrystals are grown at low temperatures (50 to 100°C for HgTe, below 150°C for PbS), reducing the energy consumption compared to traditional growth methods in which high temperatures (500°C and more) are commonly used. The introduction of photonic structures that focus the incident light over a thin nanocrystal layer also appears as a complementary strategy to further reduce the quantity of material per device. Aside from the advantage of minimizing the amount of heavy metal used, photonic structures have the added benefit of increasing light absorption over small distances. This is crucial since it has been established that the conduction occurs in infrared HgTe NC arrays throughout hopping between puddles of strongly coupled NCs 11 , leading to small diffusion lengths. As a result, there is a strong interest in matching the device size, the carrier diffusion length [START_REF] Chu | Infrared Photoconduction at the Diffusion Length Limit in HgTe Nanocrystal Arrays[END_REF] and the spatial extension of the electromagnetic field.

Various photonic concepts [START_REF] Chen | Integration of Colloidal Quantum Dots with Photonic Structures for Optoelectronic and Optical Devices[END_REF] have been proposed to enhance the absorption efficiency and shape the absorption spectrum: flat lenses [START_REF] Ning | Simulation of Monolithically Integrated Meta-Lens with Colloidal Quantum Dot Infrared Detectors for Enhanced Absorption[END_REF] , Fabry-Perot resonators, magnification of the field by metal tip [START_REF] Chen | Photocurrent Enhancement of HgTe Quantum Dot Photodiodes by Plasmonic Gold Nanorod Structures[END_REF] , plasmonic cavities [START_REF] Zhu | Integrated Plasmonic Infrared Photodetector Based on Colloidal HgTe Quantum Dots[END_REF][START_REF] Yifat | Mid-IR Colloidal Quantum Dot Detectors Enhanced by Optical Nano-Antennas[END_REF][START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF] , Bragg mirrors [START_REF] Tang | Acquisition of Hyperspectral Data with Colloidal Quantum Dots[END_REF] , guided-mode resonators [START_REF] Chu | Near Unity Absorption in Nanocrystal Based Short Wave Infrared Photodetectors Using Guided Mode Resonators[END_REF][START_REF] Gréboval | Ferroelectric Gating of Narrow Band-Gap Nanocrystal Arrays with Enhanced Light-Matter Coupling[END_REF] , metal-insulator-metal cavities [START_REF] Dhawan | Fabrication of Efficient Single-Emitter Plasmonic Patch Antennas by Deterministic In Situ Optical Lithography Using Spatially Modulated Light[END_REF] , metasurfaces [START_REF] Đorđević | Metasurface Colloidal Quantum Dot Photodetectors[END_REF] , epsilon-near-zero resonances [START_REF] Caligiuri | A Semi-Classical View on Epsilon-Near-Zero Resonant Tunneling Modes in Metal/Insulator/Metal Nanocavities[END_REF][START_REF] Caligiuri | Planar Double-Epsilon-Near-Zero Cavities for Spontaneous Emission and Purcell Effect Enhancement[END_REF] , Helmholtz resonators [START_REF] Abadie | Helmholtz Resonator Applied to Nanocrystal-Based Infrared Sensing[END_REF] as well as combinations of these [START_REF] Dang | Broadband Enhancement of Mid-Wave Infrared Absorption in a Multi-Resonant Nanocrystal-Based Device[END_REF][START_REF] Tang | Thermal Imaging with Plasmon Resonance Enhanced HgTe Colloidal Quantum Dot Photovoltaic Devices[END_REF] . The first purpose for these photonic structures is to modify either the magnitude or the linewidth of the absorption. However, it has also been proposed that photonic structures can actively modify the shape of the spectrum [START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF][START_REF] Dang | Nanocrystal-Based Active Photonics Device through Spatial Design of Light-Matter Coupling[END_REF] after the device is fabricated. For this, two requirements should be met: (i) the photonic structure needs to generate an inhomogeneous absorption map within the device, (ii) the charge collection needs to be electric field dependent. The last condition is an inherent property of hopping conduction [START_REF] Xing | Effect of Positional Disorders on Charge Transport in Nanocrystal Quantum Dot Thin Films[END_REF][START_REF] Nenashev | Effect of Electric Field on Diffusion in Disordered Materials. I. One-Dimensional Hopping Transport[END_REF][START_REF] Nenashev | Effect of Electric Field on Diffusion in Disordered Materials. II. Two-and Three-Dimensional Hopping Transport[END_REF][START_REF] Richert | Diffusion and Drift of Charge Carriers in a Random Potential: Deviation from Einstein's Law[END_REF][START_REF] Arkhipov | A Model of Weak-Field Quasi-Equilibrium Hopping Transport in Disordered Materials[END_REF] . By combining these two effects, the photocurrent will only drag the charges photogenerated in the vicinity of the electrode under low bias, whereas charge collection is possible from further away when a larger bias is applied. Since the spatial distribution of the absorption field map varies with the wavelength, one can use this effect to generate a bias-reconfigurable photoresponse. However, the magnitude of the effect reported [START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF][START_REF] Dang | Nanocrystal-Based Active Photonics Device through Spatial Design of Light-Matter Coupling[END_REF] so far remains too weak to be used, asking for the development of alternative structures. Here, we explore the coupled Fabry-Perot [START_REF] Fix | High-Quality-Factor Double Fabry-Perot Plasmonic Nanoresonator[END_REF][START_REF] Fix | Dark-Modes Excitation in Coupled Nano Fabry-Perot Structure Induced by Symmetry Breaking[END_REF][START_REF] Matthia | High-Efficiency Second-Harmonic Generation in Coupled Nano Fabry-Perot Thin Resonators[END_REF][START_REF] Guo | Cooperative Optical Trapping in Asymmetric Plasmon Nanocavity Arrays[END_REF] resonator. This structure relies on two coupled Fabry-Perot resonators. Individually, each of them is designed to operate below critical coupling. However, thanks to their coupling, critical coupling condition with free-space radiation can be achieved. Beyond the anticipated strong absorption, such cFP is also promising since it may reduce the required number of periods to generate the resonance compared to the quasi-infinite grating necessary for plasmonic and guided-mode resonators [START_REF] Chu | Near Unity Absorption in Nanocrystal Based Short Wave Infrared Photodetectors Using Guided Mode Resonators[END_REF][START_REF] Gréboval | Ferroelectric Gating of Narrow Band-Gap Nanocrystal Arrays with Enhanced Light-Matter Coupling[END_REF] . As a result, such geometry may be compatible with a reduction of the pixel size, which is often sought-after for infrared imagers.

RESULTS AND DISCUSSION

We start by growing a semiconductor to absorb the short-wave infrared spectral range. To do so, we use colloidally prepared HgTe NCs [START_REF] Gréboval | Mercury Chalcogenide Quantum Dots: Material Perspective for Device Integration[END_REF][START_REF] Keuleyan | Synthesis of Colloidal HgTe Quantum Dots for Narrow Mid-IR Emission and Detection[END_REF] . The particle size is chosen so that the particles present a 2 µm cut-off wavelength after ligand exchange [START_REF] Lan | Quantum Dot Solids Showing State-Resolved Band-like Transport[END_REF][START_REF] Martinez | HgTe Nanocrystal Inks for Extended Short-Wave Infrared Detection[END_REF] , see Figure 1a. The ligand exchange increases the inter-NC coupling and renders the film photoconductive. This procedure generally comes with a small redshift of the absorption edge, see Figure 1a. It is also associated with a strong reduction of the infrared absorption relative to the C-H bond resonance as the number of free ligands and the ligand length get reduced.

To design a NC based active device which spectral response can be tuned through bias application, the role of the photonic structure is to induce an inhomogeneous absorption map. In previous devices [START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF][START_REF] Dang | Nanocrystal-Based Active Photonics Device through Spatial Design of Light-Matter Coupling[END_REF] , two electromagnetic modes have been used: one, close to the electrode, will prevail under low electric field and the second, away from the electrode, will contribute to photocurrent only when the applied bias increases the diffusion length. Here, we adopt a different approach and directly design a bicolor structure where the two modes are spatially disjoint. To do so, we use a grating structure with two patterns per period, see Figure 1b.

Figure 1 Coupled Fabry-Perot resonator. a. Absorption spectra of the HgTe NCs used as infrared light absorbers, when capped with either long ligands (DDT) or short ligands (ink). b. Scheme of coupled Fabry-Perot resonators. c. Simulated absorption spectra within the NCs for the structure of part b and for the volume delimited by the small and large gaps.

To generate a resonance that is matched with the NC band-edge, we select a 1 µm period for the grating and the openings are chosen to be 200 and 400 nm for the small and big gap structures respectively, see Figure 1b, S3-5 for impact of geometrical fator on the ndevice absorption spatra and Figure S5 for the details of the fabrication procedure. This structure is analog to a coupled Fabry Perot structure [START_REF] Fix | High-Quality-Factor Double Fabry-Perot Plasmonic Nanoresonator[END_REF][START_REF] Fix | Dark-Modes Excitation in Coupled Nano Fabry-Perot Structure Induced by Symmetry Breaking[END_REF][START_REF] Matthia | High-Efficiency Second-Harmonic Generation in Coupled Nano Fabry-Perot Thin Resonators[END_REF][START_REF] Guo | Cooperative Optical Trapping in Asymmetric Plasmon Nanocavity Arrays[END_REF] in which none of cavity reaches critical coupling, which limits the associated absorption. Once the two patterns of a period are coupled within a single structure, a coupled mode is generated with a stronger absorption than the one obtained for the two individual resonators, see Figure 1c.

For the sake of clarity, the Figure 1b scheme is shown with NC only within the groove but in practice the spin coating deposition leads to the formation of quasi conformal film with NCs both in the gaps and on top of the gold digits. In the rest of the paper, we account in the simulation for the presence of the film on top of the electrodes, see Figure S1. Absorption reaches 80% for a film thickness of only 75 nm in TM polarization, corresponding to an effective absorption coefficient ≈10 5 cm -1 . This value is ≈30 times higher than the absorption coefficient of the HgTe NC thin film alone, which is typically around 3x10 3 cm -1 .

In addition, we take benefit of the field cancellation at the bottom of the structure at resonance to replace a thin layer of the structure by a transparent dielectric layer of Al2O3.The latter allows the grating to be used not only as a photonic structure but also as interdigitated electrodes to collect a photocurrent.

To further characterize this cFP resonator, we have coupled electromagnetic simulations with infrared scanning near-field optical microscopy (SNOM) measurements, see Figure 2. Experimentally, conducting the SNOM measurement on cFP coated with NCs is challenging. Thus, to mimic the nanocrystal film, we replace it with a harder dielectric thin film of Si3N4 whose refractive index (nSi3N4 =2) is comparable to the one of the NC film [START_REF] Rastogi | Complex Optical Index of HgTe Nanocrystal Infrared Thin Films and Its Use for Short Wave Infrared Photodiode Design[END_REF] (nNC=2.35±0.1). The Si3N4 layer thickness has also been adjusted (140 nm) such that the main cFP resonance matches the laser source (λ=1.55 µm) of the SNOM setup, as pointed by reflectivity spectra in Figure S8.

Top views of simulated electric field maps are given in Figure 2b andc, respectively, in the TM and TE polarization. The simulation predicts that (i) the signal is polarized, with a TM polarization much more intense than the TE one and (ii) along the TM polarization, the signal at the main resonance (λ = 1.53µm) is mainly localized within the large gap, see Figure 2b and S1. Electric field maps (Figure 2b-c) have been simulated using the same configuration and including the 60° angle between the normal to the sample and the tip. The topography map (Figure 2d) shows a periodic structure presenting both large (highlighted with blue arrows) and narrow grooves (highlighted with red arrows). The experimental maps of the electric field are given in Figure 2e and f, respectively, in TM and TE polarization. As predicted (Figure 2b-c), the magnitude of the field is much weaker along the TE polarization. We can correlate the maximum field magnitude with the location of the large grooves. ) and TE (f.) polarization, obtained from the third order demodulation of the SNOM signal. Now that the optical behavior of the cFP is established, we can focus on its photoconductive properties. The charge collection is determined by the way the grating is used as electrode. Various configurations can be implemented, see Figure 3a-b. Here we focus on two of them: the 'interdigitated" configuration (Figure 3a and S9), in which two consecutive digits are connected to opposite electrodes, and the "tuning fork" configuration (Figure 3b and S10-11), where the small grooves separate digits connected to the same electrode. In the tuning fork configuration, the electrostatic field resulting from bias application is only applied over the large gap, whereas in the interdigitated configuration, the electrostatic field is applied over both the large and narrow gaps.

The photocurrent spectra obtained using the tuning fork configuration depict a single resonance with a very weak bias dependence, see Figure 3d and S10. On the other hand, the photocurrent spectrum of the interdigitated configuration can significantly be tuned with bias.

In the interdigitated configuration, under low bias, we only observe one peak whose energy matches the main resonance of the cFP. Once a stronger electric field is applied, a second contribution at lower energy appears in the spectrum, see Figure 3c. The bias dependence of the cFP can be rationalized as follows: since the absorption is stronger in the larger gap (Figure 1c), the photocurrent from the large gap prevails at low electric fields. When the bias is increased, the electrostatic field gets more important over the narrow gap, which is twice as small, and charges generated in the narrow gap are more effectively collected. [START_REF] Lan | Quantum Dot Solids Showing State-Resolved Band-like Transport[END_REF][START_REF] Chu | Infrared Photoconduction at the Diffusion Length Limit in HgTe Nanocrystal Arrays[END_REF][START_REF] Xing | Effect of Positional Disorders on Charge Transport in Nanocrystal Quantum Dot Thin Films[END_REF][START_REF] Nenashev | Fundamental Characteristic Length Scale for the Field Dependence of Hopping Charge Transport in Disordered Organic Semiconductors[END_REF] As a result, the higher the field, the more efficiently the narrow gap contributes to the photocurrent. This effect combines not only the higher magnitude of the electric field in the narrow gap but also the more efficient hopping conduction at short distance. In other words, the bias is used to tune the ratio of the photocurrent signals generated within the two Fabry-Perot cavities. This interpretation is consistent with the lack of bias dependency of the response in the tuning fork configuration, which collects solely the photocurrent generated within the large gap. A small shift can be noticed between the spectra of the tuning fork and the large gap contribution of the interdigitated configuration. This can be fully correlated to NC film thickness determined by profilometry, see Figure S2.

Using the cFP structure, it is possible to turn-on and -off the photocurrent in the 1.6 to 1.9 µm range with the bias as a control knob, see the inset of Figure 3c. The magnitude of the modulation reaches a factor of 25, which is far more than the previously reported bias-induced spectrum modifications [START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF][START_REF] Dang | Nanocrystal-Based Active Photonics Device through Spatial Design of Light-Matter Coupling[END_REF] that only modified the magnitude of the signal without affecting the spectral shape [START_REF] Efros | Evaluating the Potential of Using Quantum Dots for Monitoring Electrical Signals in Neurons[END_REF][START_REF] Rowland | Electric Field Modulation of Semiconductor Quantum Dot Photoluminescence: Insights Into the Design of Robust Voltage-Sensitive Cellular Imaging Probes[END_REF][START_REF] Scott | Time-Resolved Stark Spectroscopy in CdSe Nanoplatelets: Exciton Binding Energy, Polarizability, and Field-Dependent Radiative Rates[END_REF][START_REF] Xie | Voltage-Controlled Reversible Modulation of Colloidal Quantum Dot Thin Film Photoluminescence[END_REF] . Compared with Stark modulation, the bias reconfigurability of the cFP structure also enables operation under a strongly reduced electric field since it has been predicted that, in HgTe NC arrays, electric fields above 100 kV.cm -1 are required to obtain a shift of only 30 nm [START_REF] Dang | Bias Tunable Spectral Response of Nanocrystal Array in a Plasmonic Cavity[END_REF] . Here, fields 10 times lower can displace the response by more than 250 nm. It is worth mentioning that the bias required to generate the effect is compatible with the typical bias applied by a CMOS readout circuit (3 V typically).

Figure 3 Bias reconfigurable photoresponse. Scanning electron microscopy image of coupled

Fabry-Perot structure connected using interdigitated (a.) or tuning fork (b.) configuration. c. Unpolarized photocurrent spectra under various biases in the interdigitated configuration, measured at 250 K. The inset shows the bias dependence of the ratio of intensities between the signal at 1.7 µm and the one at 1.5 µm. d. Photocurrent spectra under various biases in the tuning fork configuration, measured at 250 K. e. Responsivity under illumination from a black body at 980°C (i.e., broadband) as a function of the applied bias, measured at 295 K. f. Specific detectivity as a function of the device temperature, measured at 1 V and 1 kHz. The inset shows the noise current spectral density as a function of the signal frequency, measured at three different temperatures.

As an infrared photodetector, the cFP structure can lead to a responsivity as high as 2 A.W -1 under broadband blackbody illumination, see Figure 3e. This corresponds to an external quantum efficiency of around 120%, suggesting the presence of photoconductive gain [START_REF] Konstantatos | Colloidal Quantum Dot Photoconductive Photodetectors: Transport, Traps, and Gain[END_REF] . The latter is favored by the short interelectrode spacing [START_REF] Chu | Infrared Photoconduction at the Diffusion Length Limit in HgTe Nanocrystal Arrays[END_REF] , since the gain scales as

𝜏 𝑐𝑎𝑟𝑟𝑖𝑒𝑟 𝜏 𝑡𝑟𝑎𝑛𝑠𝑖𝑡
with 𝜏 𝑐𝑎𝑟𝑟𝑖𝑒𝑟 the photocarrier lifetime and 𝜏 𝑡𝑟𝑎𝑛𝑠𝑖𝑡 the transit time, i.e. the duration for the carrier to go across the channel. A shorter electrode spacing allows a faster crossing and thus magnifies the gain. The noise in the structure remains limited by 1/f contribution [START_REF] Liu | 1/f Noise in Semiconductor and Metal Nanocrystal Solids[END_REF][START_REF] Geremew | Low-Frequency Electronic Noise in Superlattice and Random-Packed Thin Films of Colloidal Quantum Dots[END_REF] , see the inset of Figure 3f, which currently limits the specific detectivity of the structure to 2x10 10 jones when operating at 200 K. This value is typically higher than the one reported for photoconductive geometries that do not implement a light management strategy, but it still remains smaller than the one of state-of-the-art devices based on the same material at the same wavelength, see table S1. Conversely, the cFP structure is the one presenting the strongest spectral reconfigurability. By changing the number of periods of the grating and the electrode length, we also have investigated the impact of the device size (i.e. size of the grating) on the device response, see Figure 4 and S7. We notice that smaller devices present a larger responsivity, see Figure 4a. This suggests a possible antenna effect that enables photon collection outside of the cFP structure. In Figure 4b, we have simulated absorption in the NC layer with different sizes of the illumination spot for a 5period cFP (i.e., the structure size of 5 μm). Figure 4b compares our simulated NC absorption with the theoretical NC absorption in the absence of antenna effect (i.e., the structure only absorbs radiation impinging on its physical area). When the spot size is larger than the device's physical size, the cFP structure shows a stronger absorption than the one obtained without antenna effect, implying photon collection outside the grating area. The difference in absorption with and without antenna effect is presented as a function of the distance to the device in the inset of Figure 4b and presents a maximum at around 2 μm, which is very close to the resonance wavelength of the cFP device. In other words, the cFP can collect photons 2 µm away from the grating, it is thus of high interest to shrink the device size to maximize the benefit of this "free" absorption, by reducing at the same time the noise. [START_REF] Palaferri | Room-Temperature Nine-Μm-Wavelength Photodetectors and GHz-Frequency Heterodyne Receivers[END_REF] In Figure 4c andd, we have measured the photocurrent spectra for various device sizes while electrodes are connected in the tuning fork configuration. The characteristic resonance of the cFP along the TM polarization is well observed for pixel size down to 10 µm. This suggests that this geometry of the resonator might be compatible with the next generation of imagers in the short-wave infrared in which pixel size below 10 µm will be targeted. However, a structure only including 5 periods (5 µm size) does not present the cFP resonance. Simulation (Figure 4f) clearly shows that the external periods of the structure that are only coupled to a single Fabry-Perot on one side presents a reduced absorption. This observation certainly sets the smallest dimension the cFP structure can be realized.

Conclusion

To summarize, we have described a new type of resonator that can increase the absorption of an infrared NC film. The cFP structure comprises a grating with two patterns per period. It leads to an effective increase of the absorption coefficient by a factor of almost 30 in the TM polarization, reaching now a value of approximately 10 5 cm -1 . Beyond the enhanced absorption, the cFP device enables the design of a bias-reconfigurable photoresponse. The photocurrent signal over a 300 nm spectral region can be turned on and off by a factor of 25 by using only low driving voltage (<1 V, which is fully compatible with CMOS read-out circuits). Beyond the benefit of bringing NC as an active medium for nanophotonics, such reconfigurability of the response is interesting to generate band rejection filtering, which could prevent blurriness of the sensor by countermeasures. In addition, the cFP device presents an antenna effect and enables photon collection from outside the structure over a distance that matches the resonance wavelength in the structure. cFP also shows great potential for being transferred at the imager level since it does not require an infinite grating to be effective, and resonance is observed for pixel sizes as small as 10 µm.

Figure 2

 2 Figure 2 Infrared near-field microscopy characterization of coupled Fabry-Perot structure. a. Schematic of the SNOM measurements on a coupled Fabry-Perot structure in which the NC layer is replaced by a thin Si3N4 film. The incident light comes with a 60° angle. Simulated square of the electric field map at 1.55 µm in TM (b.) and TE (c.) polarization. d. Topography map of the coupled

Figure 4

 4 Figure 4 Antenna effect and potential for small pixel design. a. Responsivity as a function of the incident irradiance under 1V, measured at 295 K, for several device sizes. b. Simulated Absorption in NC layer as the illumination spot size increases. The inset shows the NC absorption gained due to the antenna effect as a function of distance to the grating area. c. Normalized photocurrent spectra under 1V, along TM polarization for various pixel sizes. d. Normalized photocurrent spectra under 1V, along TE polarization for various pixel sizes. e. Scanning electron microscopy image of the coupled Fabry-Perot structure with 5 periods. f. Simulated absorption spectra for each period of the device are depicted in part (e.) The dashed line is the average absorption

FUNDING SOURCES

The project is supported by ERC grant blackQD (grant n° 756225) and AQDtive (grant n° 101086358). We acknowledge the use of clean-room facilities from the "Centrale de Proximité Paris-Centre". This work was supported by French state funds managed by the ANR more specifically within the grants IPER-Nano2 (ANR-18-CE30-0023), Copin (ANR-19-CE24-0022), Frontal (ANR-19-CE09-0017), Graskop (ANR-19-CE09-0026), NITQuantum (ANR-20-ASTR-0008-01), Bright (ANR-21-CE24-0012-02), MixDferro (ANR-21-CE09-0029) and Quicktera (ANR-22-CE09-0018).

Supporting Information

Supporting Information include (i) method for nanocrystal synthesis, (ii) electromagnetic design, fabrication procedure and near field microscopy of the cFP structure (iii) additional photocurrent spectra as a function of bias and temperature and (iv) comparison with state-of-the-art device based on nanocrystal film coupled to photonic structure.

COMPETING INTEREST

The authors declare no competing financial interests.