Julian Zach
email: julian.zach@t-online.de

Hans P Reiser

LiveCloudInspector: Towards Integrated IaaS Forensics in the Cloud

Cloud-based systems are becoming an increasingly attractive target for malicious attacks. In IaaS environments, malicious attacks on a cloud customer's virtual machine may affect the customer, who cannot use all diagnostic means that are available in dedicated in-house infrastructures, as well as the cloud provider, due to possible subsequent attacks against the cloud infrastructure and other co-hosted customers. This paper presents an integrated approach towards forensics and incident analysis in IaaS cloud environments. The proposed architecture enables the cloud provider to securely offer forensics services to its customers on a self-service platform. The architecture combines three important analysis techniques and provides significantly better investigation capabilities than existing systems: First, it supports host-based forensics based on virtual machine introspection. Second, it offers live remote capture of network traffic. Third, and most importantly, it provides hybrid combinations of the first two techniques, which enables enhanced analysis capabilities such as support for monitoring encrypted communication.

Introduction

Motivation

The increasing shift of resources towards the cloud makes it necessary to deal with new IT security challenges. As more and more resources are out-sourced into the cloud, these will be a more likely target of malicious activities. Traditional mechanisms for investigating such incidents are, to large extent, insufficient.

A basic problem is the separation between cloud provider and cloud user. In an Infrastructure-as-a-Service (IaaS) cloud, the cloud customer is responsible for all software layers within a virtual machine, but in case of a security incident, the customer cannot apply traditional investigation approaches and tools that require direct access to the physical hardware. On the other hand, the cloud provider has no knowledge about internals of the customer's virtual machines and thus is also in a weak position for an in-depth investigation. A second important challenge is multi-tenancy. Significant efficiency benefits of cloud computing stem from the shared use of resources by multiple customers. A fundamental requirement of cloud infrastructures is the strict separation between multiple tenants using shared physical hardware. An investigation of one customer must not affect the availability, integrity or confidentiality of resources used by other customers.

Problem statement

It is straight-forward to use existing post-incident investigation tools that analyse static main memory snapshots or analyse log files created during system execution in an IaaS cloud environment. Main memory snapshots can efficiently be created from within active virtual machines, and log files can be obtained from the system within the virtual machine as well as from the cloud management system. A fundamental limitations of these approaches, however, is that they enable only static a-posteriori analysis. What is currently missing are appropriate methods for direct live investigations on a running system.

In this paper we propose a novel, integrated architecture for live IaaS forensics. The architecture enables the cloud provider to offer forensics services to customers via a secure interface. The architecture, which we implemented in the LiveCloudInspector prototype, makes three important contributions:

-It enables remote host forensics based on virtual machine introspection (VMI) with a self-service interface for customers; -It enables efficient, transparent remote network forensics in IaaS cloud infrastructures; -It offers novel analysis capabilities that yield additional insight by combining host and network forensics.

The combined analysis makes important contributions to enhancing the investigation process. Specifically, it enables correlating recorded network traffic with running processes, indicating exactly to which process data has been sent to or received from; it supports dedicated network monitoring of selected processes; and it supports transparent monitoring of encrypted network traffic using VMI-based session key extraction.

This paper is structured as follows: In the next section, we discuss related work. In Section 3, we summarize the network monitoring and virtual-machine introspection mechanisms our work builds upon. Section 4 presents our architecture. Section 5 describes and evaluates our prototype implementation. Finally, we present our conclusions in Section 6.

Related Work

The problem of incident investigation in cloud computing environments has gained some attention only in the recent years. Birk et al. [START_REF] Birk | Technical issues of forensic investigations in cloud computing environments[END_REF] state that the ability to perform forensic investigations in the cloud is of high relevance, but seldomly discussed. The authors argue that guidelines and best practices for investigations in the cloud are rare, often outdated, or non-existent. Similarly, Taylor et al. [START_REF] Taylor | Forensic investigation of cloud computing systems[END_REF] conclude that "currently there do not appear to be any published guidelines that specifically address the conduct of computer forensic investigations of cloud computing systems." Dykstra and Sherman [START_REF] Dykstra | Acquiring forensic evidence from infrastructure-asa-service cloud computing: Exploring and evaluating tools, trust, and techniques[END_REF] tried to deploy existing forensics tools such as Guidance EnCase in an IaaS cloud to acquire forensic data remotely over the Internet. The paper provides an excellent discussion of the limitations of such an approach. In particular, it argues why data acquired that way might not be trustworthy.

Martini and Choo [START_REF] Martini | An integrated conceptual digital forensic framework for cloud computing[END_REF] describe a conceptual framework for collecting forensic data from a cloud environment. The paper includes an extensive discussion of related work on digital forensics and cloud forensics on a broader scope than we include here as well as a high-level description of a conceptual framework. To our knowledge, no practical implementation of that framework exists so far.

In practice, the mechanism with most widespread support by existing cloud providers is the export of virtual machine snapshots1 . Such virtual machine snapshots contain data of the virtual disk, but not live data such as the main memory. They can only be used for off-line forensic investigations. Some providers implement additional features such as Amazon Cloud Watch 2 , which provides basic run-time monitoring features that collect various metrics about run-time behaviour, and Amazon Cloud Trail 3 , which records AWS API calls and delivers log-files to the customer.

FROST (Forensic OpenStack Tool) [START_REF] Dykstra | Design and implementation of FROST: Digital forensic tools for the OpenStack cloud computing platform[END_REF] has recently been presented as a forensic toolkit within the OpenStack platform. FROST collects data at the cloud provider and host operating system level und makes it available to the customer by additional API methods. These methods allow downloading API logs, firewall logs and retrieving disk images. Similar to our approach, it advocates the idea of integrating forensics tools and interfaces into a cloud platform management infrastructure. What differentiates our work from FROST are enhanced mechanisms for data acquisition and analysis, specifically supporting live analysis.

Gebhardt et al. [START_REF] Gebhardt | Network forensics for cloud computing[END_REF] implemented a network forensics tool for the cloud that extends the OpenNebula management platform. This tools allows recording network traffic on demand and delivering network traffic dumps to the customer for further investigation. The LiveCloudInspector includes a very similar approach for network monitoring, but as a main contributions adds additional data acquisition and analysis methods.

Our framework enhances these existing approaches by implementing both network and host forensics based on dynamic run-time introspection in a single integrated platform. The combination of network monitoring with host introspection yields better insights and enables useful additional mechanisms such as automated correlation of network traffic with running processes and automated decryption of encrypted TLS channels based on secret-key extraction.

Background

Virtual machine introspection

Virtual machine introspection (VMI) is an established technology in which the virtual machine monitor (VMM) transparently inspects internal data of a run-ning virtual machine. The VMM has full control of all resources of the VM (such as main memory, hard disks, and network devices), and thus is in a position for accessing all of them.

Our prototype implementation builds upon the state-of-the-art introspection library LibVMI4 , which supports both Xen and KVM hypervisors. LibVMI requires some knowledge about the OS running within the VM to interpret VM memory correctly. In this paper, we assume that such information exists a priori and can be provided statically to LibVMI. This should, for example, be the case, if the user wants to investigate its own virtual machines. In situations in which such information is not available, our system could be combined with approaches that automatically bridge this semantic gap, such as Insight-VMI [START_REF] Schneider | A universal semantic bridge for virtual machine introspection[END_REF].

The first goal of our proposed architecture is to enable remote acquisition of memory snapshots using VMI in an IaaS cloud-computing environment.

High-level memory analysis

While LibVMI offers some low-level API for transparently obtaining data from a running VM, it frequently is desirable to derive more high-level information. Several existing tools such as F-Response5 and VAD tools6 support such analysis on the basis of a static main memory snapshot. In our prototype, we use the Volatility framework 7 , which can also be combined with live VMI. Volatility has a modular architecture and, for example, includes modules that based on a target system's main memory content enumerate all processes (pslist), existing network connections (connscan), open files (filescan) and registry entries (hivelist), or extract sections of main memory of individual processes (memdump).

The second goal of our proposed architecture is to enable secure remote use of this tool in a public cloud environment.

Network monitoring background

According to Garfinkel [START_REF] Garfinkel | Network forensics: Tapping the internet[END_REF], tools for network forensics operate either host-based (such as Wireshark8 ) or network-wide (such as NIKSUN NetDetector). They either capture all network packets and store them for later analysis ("catch-it-asyou-can") or analyse packets directly after reception and store only information produced by that analysis for later further processing ("stop-look-and-listen").

Our third goal is to enable remote packet sniffing in a cloud environment, which means that we aim at designing a service that captures all network packets of a virtual machine and stores them for later analysis by the client. For such a host-based catch-it-as-you-can service, we additionally consider continuous monitoring of virtual machines that are migrated and VMI-assisted filtering of recorded traffic.

TLS decryption background

Analysis tools such as Wireshark contain protocol dissectors for hundreds of different protocols. Dissectors are able to automatically interpret and display protocol details. Wireshark is able to dissect TLS traffic, and if provided with the RSA private key, it can decrypt messages used for exchanging the RSAencrypted session key (RSA key exchange). After obtaining the session key, all subsequent TLS traffic can easily be decrypted.

Shamir et al. [START_REF] Shamir | Playing "hide and seek" with stored keys[END_REF] have shown that RSA private keys can be located in main memory dumps based on algebraic properties. Such approach could be used for our system, but only with significant limitations: It works only for incoming connections (otherwise, the session key is sent to the remote host, encrypted with the remote host's public key, and the corresponding private key of the remote host cannot be retrieved locally), and it does not work with other key exchange mechanisms that offer forward secrecy, such as Diffie Hellman and ECDH.

Our goal is to reuse as much as possible of the Wireshark TLS dissector, but enhance it with VMI mechanisms that retrieve the session key from main memory. We want to be able to monitor all TLS traffic, both incoming and outgoing, and independent of the key exchange mechanisms used.

Design and Architecture

Our main goal is to design a secure system that enables cloud users and authorized third parties to perform investigations on some target VMs as a self service (i.e., without manual support by the cloud provider). In this section, we first present the role model of our approach and the high-level design, followed by a detailed description of workflows for simple and complex analysis tasks.

Role model

Various roles can be differentiated in an IaaS cloud. Figure 1 illustrates the roles that we consider. Our design makes the assumption that the cloud provider itself (including its staff) is trustworthy. We do not consider malicious insiders (such as a malicious administrator of the cloud provider). Such cases might be tackled with trusted cloud computing techniques, for example such as presented by Rocha et al. [START_REF] Rocha | The final frontier: Confidentiality and privacy in the cloud[END_REF], but this is beyond the scope of the present paper. We consider the following attacks against our architecture:

-Unauthorized malicious third parties that try to attack the forensics system from outside; -Users and external investigators that are authorized to investigate virtual machines of a specific user, but exploit the forensics system to gain access to or harm other users, violating the separation of tenants; -Attackers that deploy (as a user) their own virtual machines within the cloud infrastructure and use those as a starting point for attacks against the forensics system.

Design

Figure 2 shows an overview of the architecture of LiveCloudInspector. It distinguishes between two parts of the forensics system. First, a dedicated forensics platform implements all supported workflows as well as the public service interface. Workflows are included for low-level direct main memory dumps of virtual machines, for selected memory forensic operations, and for network forensics.

The workflow implementations interact with corresponding counterparts that are deployed as a forensic remote service on all cloud hosts. Our design does not integrate the forensics mechanisms deeply into a cloud management platform such as OpenStack9 or OpenNebula10 . Instead we aim at proposing a portable architecture that can, with little effort, be reused on multiple cloud platforms or different versions of the same platform.

Nevertheless, there are two dependencies on the cloud management system. First, we do not want to have a separate user management system. Instead, Live-CloudInspector will use a platform-specific adaptor to interact with the cloud management system for user authentication and authorization. Second, we depend on the cloud management system for locating the physical host of target virtual machines and for tracking them on migration operations. The service interface of the forensics platform is the public, remotely accessible interface for users and external investigators. After checking the authorization of a client to access the forensics platform via the cloud management system, it accepts commands for VMI, memory forensics or network forensics, retrieves the location of a virtual machine from the platform's management layer, and finally remotely interacts with the corresponding forensic remote service.

In the following, we first discuss the details of all simple workflows, which are workflows for either recording network traffic or for VMI-based host forensics, followed by a discussion of complex workflows, which use a combination of host introspection and network monitoring in order to derive more in-depth insights.

Simple workflows

Remote main memory dump is the first workflow and enables remote snapshots of the main memory of a virtual machine. Note that this is fundamentally different from the usual disk snapshot generation supported by several cloud providers. Often, relevant artefacts of problems or malicious activities manifest themselves only in main memory, and not on persistent disk storage.

In this workflow, a cloud user or an authorized investigator requests a memory dump at the LiveCloudInspector platform. The platform checks user authentication and authorization and, if access to the specified VM is granted, retrieves the physical location of the VM from the cloud management platform and requests a memory dump from the forensics remote service at the physical host. Finally, the memory dump is made available for download for the cloud user or investigator.

The advantage of this workflow is that the investigator can use any tool of his/her choice to analyse the memory dump. Under the assumption of a trustworthy cloud infrastructure and forensics service, a digital signature attached to the memory dump by the forensics remote service can guarantee the validity of the snapshot. The disadvantage of this workflow is the cost for transferring the memory dump (potentially several gigabytes for large VM instances). A further limitation of the approach is that information in CPU registers or main memory cache is not recorded in the main memory dump.

It should be noted that in fact main memory forensics in a virtual machine is much easier than main memory forensics on a traditional physical host. The main memory of a virtual machine can easily be extracted using introspection tools such as libVMI, whereas the acquisition of main memory content of physical machines requires dedicated hardware or, alternatively, software running on the host that potentially is subject to (unnoticed) alterations.

Remote memory forensics enables remote execution of more complex forensics analysis of VM memory. The data source is the same as in the first workflow (i.e., the main memory of a target virtual machine), but instead of transferring the whole memory dump to the investigator, the analysis is performed directly at the target host. For this purpose, such analysis capabilities are enabled directly as a service. In our prototype implementation, we offer remote execution of Volatility commands. Volatility supports many high-level diagnostic operations, as briefly discussed in Section 3, and is able to directly interact with VM memory using libVMI.

The advantage of this workflow is that the memory snapshots do not need to be transferred to the investigator. The main disadvantage is that only those remote forensics tools and operations are supported that have been implemented in the forensics platform. We do not support the execution of arbitrary code selected by the user, because this might raise a lot of security questions.

Network forensics yields additional information for the analysis of anomalous occurrences and intrusions by observing communication patterns. For example, some malware might be periodically communicating with a command-andcontrol server. Observing network traffic using physical access to the network is an established approach in forensics. In a public IaaS cloud, the investigator has, in most if not all cases, no direct access to physical hosts. Instead, a mechanism for remote acquisition of network traffic is required.

Multi-tenancy potentially raises additional challenges for such remote acquisition, depending on how multi-tenancy is handled by the network infrastructure used by the cloud provider. If each customer (or each VM) has its own, separate virtual network, the traffic of this virtual network can be used for investigation. If multiple tenants share the same local network, additional filtering needs to be applied to the recorded traffic in order to assure strict separation of tenants.

The network monitoring part of the LiveCloudInspector approach is based on previous work by Gebhardt et al. [START_REF] Gebhardt | Network forensics for cloud computing[END_REF]. Unlike the previous work, which integrated the forensics service deeply into OpenNebula, our focus was put on minimizing the dependency on the cloud management system. This makes LiveCloudInspector portable to other cloud management infrastructures.

The basic network capture service implements the recording of network traffic on request by the user. The traffic capture is remotely initiated by remote interaction between forensics platform and forensics remote service. In order to avoid storage overhead on the physical host where the traffic is recorded and also in order to minimize the delay between recording and analysis, each recorded packet is directly sent from the forensics remote service to the forensics platform, where it is made available for download to the investigator.

Virtual machine migration is handled by an extension of the network forensics workflow. A cloud management platform may perform live VM migration for purposes such as load balancing or maintenance operations. Many VM managers support not only cold migration (shutting down a VM and relaunching it on a different host), but also hot (live) migration (moving the VM to a different host without shut-down or interruption of client connections).

The LiveCloudInspector supports appropriate coordination mechanisms for handling continuous network capturing during VM migration, as illustrated by Figure 3. For this purpose, it is necessary to receive pre-migration and postmigration events from the cloud management platform, which enable a coordinated activation of traffic acquisition at the migration target and deactivation at the migration source after finishing the migration. Traffic from both the old and the new location are collected by the Forensics Platform and presented to the investigator as a single network capture.

Complex workflows

One of the most significant advantages of a hybrid network and host forensics approach is that data of both sources can be combined, which yields several benefits.

Process-specific network monitoring for a single process running within a virtual machine is a first example of a complex workflow. A problem of remote network forensics is that potentially large amounts of recorded data (the whole traffic of a virtual machine) need to be transferred to the investigator.

The LiveCloudInspector allows the investigator to filter the recorded traffic according to running processes within the VM. In order to achieve this, information (IP address and TCP/UDP port numbers) from the captured network is correlated with data about network connections and processes acquired by virtual-machine memory introspection. While this is similar to network forensics workflow, it has the big advantage of requiring less data to be transferred to the investigator.

Correlating process names with network traffic is a workflow that can be used for monitoring all network communication and correlating each connection with information about the communicating process on the local machine. This might yield only little benefit for incoming connections towards the virtual machine, as usually the target process will be uniquely identified by the destination port and target ports other than the intended services will likely be blocked by a firewall.

Information about corresponding processes can be of valuable benefit for outgoing connections (i.e., originating at the virtual machine under investigation). In this cases, local port numbers usually do not reveal any information about the process the connection originates from.

Monitoring encrypted TLS communication is a possibly even more interesting benefit of the combination of host and network forensics. The basic idea is that the session key of a TLS session can directly be extracted using virtual-machine introspection, and then later be used to decrypt all encrypted TLS communication.

The TLS decrypter of LiveCloudInspector can be activated by the network monitor. If a TLS connection is detected, we need to wait for the right point in time for starting the key search. The session key has been calculated by the TLS implementation after the initial TLS handshake has finished and encryption is started using a ChangeCipherSpec message. At this point in time, a main memory snapshot of the communicating process within the VM is created and the search for the session key is started concurrent to continuously recording the encrypted traffic.

Implementation and Evaluation

Implementation

We have implemented the proposed architecture in the LiveCloudInspector prototype.

This prototype is designed for working with the OpenNebula cloud management infrastructure. We tried to avoid strong dependency on a specific cloud management product, so we expect that it is easy to port our prototype to other systems. The user interface of LiveCloudInspector is not integrated internally into OpenNebula, but instead a separate web-based interface was created. For this purpose, a front-end running as Java Server Pages on an Apache Tomcat application server were implemented. The front end enables the user to activate several backends for low-level VMI access, for high-level memory introspection, and for network forensics.

The user interface interacts with OpenNebula for authenticating users. The authorization to access virtual machines via LiveCloudInspector is thus not handled with a separate user management system, instead the internal user management of OpenNebula is used. For this purposes we implemented a Custom Realm for Tomcat11 that forwards a user authentication request to OpenNebula authentication core.

A forensics remote service implemented in Java is executed on each cloud host. This service offers a remote interface for interaction with the forensics server. We used SIMON Remote 12 for implementing calls from the server to the remote service, as it is easier to deploy than standard Java RMI. The remote service uses TLS with additional client authentication to make sure that only the forensics server can interact with the remote service.

Our current prototype for the TLS decryption assumes that the session key is directly stored in main memory as a byte array. So far, we successfully validated our key extractor with OpenSSL, JSSE, GnuTLS and Microsoft Schannel implementations. We directly use the decryption functionality of the Wireshark TLS dissector, and thus our implementation works with all TLS ciphers supported by Wireshark.

Rootkit case study

As a first use case we considered a virtual machine infected by the Linux rootkit KBeast. This rootkit is installed as a kernel module and implements features such as key logging and a remote backdoor. The rootkit takes various measures for hiding itself from the user. For example, it hides itself from commands listing the loaded kernel modules (such as lsmod ), it hides the backdoor process from the process list, and hides network connections of the backdoor from tools such as netstat. It is, thus, difficult to detect the rootkit by tools running within the virtual machine.

Using our LiveCloudInspector prototype, we were able to remotely execute volatility functions, e.g., to extract information about kernel modules, network connections, and process lists via VM introspection. As the rootkit is not able to manipulate the information extracted using VMI, we were immediately able to distinguish between an infected and a correct virtual machine.

Security evaluation

Our IaaS forensics architecture aims at enhancing the security of cloud computing by enhancing the capabilities for incident analysis, but it also represents an additional component that increases the system's complexity and attack surface and possibly causes additional security risks. We therefore discuss protection mechanisms included in our architecture against the threads described in Section 4.1.

Unauthorized malicious third parties that try to attack the forensics system from outside can interact with the service interface of the forensics platform. Our prototype implements client authentication by delegation to the OpenNebula platform. Assuming a correct implementation of the authorization system in the forensics platform, only users that can access the cloud management platform can access the forensics platform.

Clients that are valid users and thus successfully authenticate to the forensics platform might try to acquire information about other users, violating the strict separation of tenants. In our system, for both network and host forensics, OpenNebula's VM-ID is used to identify the target virtual machine. For all operations, OpenNebula is contacted for all access to that VM-ID, and OpenNebula checks the user's authorization. Only users that are authorized to access a virtual machine via the OpenNebula API are allowed to access it via the forensics platform.

User input is also used in the interaction between the forensics platform's backends and the forensic remote services. In particular, for remote memory forensics, the user has a lot of control over arguments passed to the Volatility tool. Careful input validation is necessary in order to avoid possible injection attacks at this interface.

The Forensic Remote Service can also be a target of malicious attacks, originating either from outside or from a virtual machine within the cloud infrastructure. Besides blocking such interaction at the network level using firewall rules we additionally implemented two-way authentication between the Forensics Platform and Forensics Remote Services, making this kind of attack infeasible.

Limitations

A frequently discussed limitation of introspection-based tools for malware analysis is split-personality malware. Examples such as RedPill and variants [START_REF] Paleari | A fistful of red-pills: How to automatically generate procedures to detect cpu emulators[END_REF] show that it is easy for malware to detect whether it is running in a virtualized environment and thus could behave differently than in a production environment. This issue is not a problem for our approach, as we apply VMI directly in the production environment.

What is a potential problem are attempts to subvert VMI, as shown for example by DKSM [START_REF] Bahram | DKSM: Subverting virtual machine introspection for fun and profit[END_REF]. Our current prototype implementation is based on LibVMI, which relies on the assumption that the provided kernel system map corresponds to the actual kernel in the VM. If the layout of kernel data structures is altered by malware within the virtual machine, VMI can possibly produce wrong data. This is not a direct limitation of our architecture itself, but is an implication of the introspection mechanism in use, and the investigator using our system needs to be aware of this potential problem. The development of more robust introspection solutions that are not vulnerable to such attacks will help to remedy this limitation.

Our monitoring approach for encrypted communication works for traffic that uses standard implementations of TLS. We assume that session keys are stored in main memory (which all popular implementations of TLS that we are aware of do), and that traffic is encrypted according to the specification of TLS. This is most likely true for all software intentionally running within the virtual machine (this is under full control of the user of the VM). Often, even malware uses standard TLS for communication on command-and-control channels, but this could easily be replaced by some other proprietary encryption mechanisms. Our prototype will not be able to decrypt such connections that use encryption methods different to standard TLS.

Conclusions

In this paper, we have presented the design and implementation of LiveCloudInspector. LiveCloudInspector enables forensics as a service in public cloud environments. The architecture combines, in a single system, three mechanisms that support the analysis of security incidents:

-It enables transparent live host forensics based on virtual-machine introspection. This feature includes both the possibility of acquiring low-level memory snapshots and the possibility of analysing the running system with high-level Volatility commands. -It enables remote network forensics by implementing a live network traffic capture mechanism. This mechanism makes sure that captured data is filtered correctly in a multi-tenant environment, and it also supports virtual machine migration during the capture process. -It combines network monitoring with VMI-based host analysis. This yields interesting new analysis capabilities, such as directly monitoring traffic of specific processes, correlating information about processes with network traffic, and secret key extracting for monitoring encrypted TLS communication.

The session key extraction works for both incoming and outgoing connections, it even supports channels established with perfect forward secrecy (i.e., Diffie-Helman based session key establishment), and unlike interceptionbased approaches it is fully transparent for the communication endpoints.

With these contributions, our architecture enhances the possibilities for investigating security incidents in infrastructure-as-a-service cloud environments.

Fig. 1 .

 1 Fig. 1. Trusted and untrusted roles in the LiveCloudInspector architecture: The cloud service provider (CSP) including its staff is trusted, while all other parties (external investigators, users, VMs hosted by the CSP) are untrusted.

Fig. 2 .

 2 Fig. 2. The LiveCloudInspector architecture adds two components to a cloud environment: A dedicated Forensics Platform and decentralized Forensics Remote Services deployed on all cloud hosts.

Fig. 3 .

 3 Fig. 3. This image illustrates the high-level interactions between forensics platform (bottom host) and forensics remote service (all other hosts) during VM migration.

http://aws.amazon.com/ec2/vm-import/ [validated on

2014-09-20] 2 http://aws.amazon.com/cloudwatch [validated on 2014-09-20] 3 http://aws.amazon.com/cloudtrail [validated on 2014-09-20]

https://code.google.com/p/vmitools/ [validated 2014-09-20]

https://www.f-response.com/ [validated 2014-10-20]

http://vadtools.sourceforge.net[validated 2014-10-20]

http://www.volatilityfoundation.org [validated 2014-09-20]

https://www.wireshark.org [validated 2014-09-20]

http://www.openstack.org[validated 2014-09-20]

http://opennebula.org[validated 2014-09-20]

http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html[validated 2014-10-20]

Acknowledgments

The research leading to these results was supported by the "Bavarian State Ministry of Education, Science and the Arts" as part of the FORSEC research association.


Damien Sorigué

Bertrand Legeret

Stéphan Cuiné

Stephanie Blangy

Solène Y Moulin

Emmanuelle Billon

Pierre Richaud

Sabine Brugière

Yohann Couté

Didier Nurizzo

Damien Sorigué

Bertrand Légeret

Stéphanie Blangy

Pavel Müller

Klaus Brettel

David Pignol

Pascal Arnoux

Yonghua Li-Beisson

Gilles Peltier

Fred Beisson
email: frederic.beisson@cea.fr

An algal photoenzyme converts fatty acids to hydrocarbons

à la diffusion de documents scientifiques 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.

In both photosynthetic and nonphotosynthetic organisms, light is involved in biological processes such as growth, development, metabolism, and circadian entrainment [START_REF] Thompson | Sancar Photolyase/cryptochrome blue-light photoreceptors use photon energy to repair DNA and reset the circadian clock[END_REF][START_REF] Greenham | McClung Integrating circadian dynamics with physiological processes in plants[END_REF][START_REF] Yoshii | Helfrich-Förster Cryptochrome-dependent and -independent circadian entrainment circuits in Drosophila[END_REF][START_REF] Fuller | Fungal photobiology: Visible light as a signal for stress, space and time[END_REF]. In most cases, the effects of light on cell physiology are mediated by photoactive proteins, which include light-sensitive ion channels and pumps, photoreceptors, photosynthetic antenna proteins, and light-dependent enzymes [START_REF] Björn | Photoactive proteins[END_REF]. Among the latter, two different types can be distinguished. Light-activated enzymes require only a flash of light to become active, whereas photoenzymes require a continuous flux of photons to remain catalytically active-their activity is driven by light.

Photoenzymes are a rare type of catalyst. In nature, two families of proteins bearing a light-driven activity are DNA photolyases, which are involved in repairing ultraviolet (UV) damage in DNA in many organisms, from bacteria to plants and animals (6-8), and light-dependent protochlorophyllide reductases, which catalyze chlorophyll synthesis (9). Chlorophyll f synthase might be a third type of photoenzyme, but the light-driven nature of the reaction has not been established [START_REF] Ho | Bryant Light-dependent chlorophyll f synthase is a highly divergent paralog of PsbA of photosystemII[END_REF]. The multimeric complexes that form the basis of oxygenic photosynthesis-plastocyanin:ferredoxin oxidoreductase (often referred to as photosystem I) [START_REF] Melkozernov | Light harvesting in photosystem I supercomplexes[END_REF] and water:plastoquinone oxidoreductase (photosytem II) [START_REF] Renger | Renger Photosystem II: The machinery of photosynthetic water splitting[END_REF], as well as related proteins in nonoxygenic photosynthetic bacteria-may also be classified as photoenzymes [START_REF] Björn | Photoactive proteins[END_REF].

Photoenzymes are useful tools for research and biotechnology. For example, lightcontrolled catalysis allows the study of rapid enzymatic processes in real time [START_REF] Zhong | Ultrafast catalytic processes in enzymes[END_REF]. And, the use of a photoexcited cofactor to design an enzyme with a different catalytic function [START_REF] Emmanuel | Hyster Accessing non-natural reactivity by irradiating nicotinamide-dependent enzymes with light[END_REF][START_REF]Bornscheuer Chemical biology: A radical change in enzyme catalysis[END_REF] as well as the development of optogenetics [START_REF] Shcherbakova | Verkhusha Natural photoreceptors as a source of fluorescent proteins, biosensors, and optogenetic tools[END_REF][START_REF] Zhang | Optogenetic control of intracellular signaling pathways[END_REF] expands the scope of possible applications of enzymes driven by light. Some microalgae, including Chlorella variabilis NC64A and Chlamydomonas reinhardtii 137C, have the capacity to convert long-chain fatty acids to alkanes or alkenes in a process dependent on light [START_REF] Sorigué | Beisson Microalgae synthesize hydrocarbons from long-chain fatty acids via a light-dependent pathway[END_REF]. Because no homologs to known hydrocarbon-forming enzymes have been found in the genomes of C. variabilis or C. reinhardtii, we hypothesized that microalgae harbor a different type of alkane synthase. Conversion of microalgal fatty acids to hydrocarbons has been mostly studied in Botryococcus braunii [START_REF] Dennis | Kolattukudy A cobalt-porphyrin enzyme converts a fatty aldehyde to a hydrocarbon and CO[END_REF]. Here, we identify an alkane synthase in the green microalgae C. variabilis and show that it is a photoenzyme belonging to an algaespecific subfamily of proteins that has been conserved throughout algal evolution.

Results

Identification of a microalgal alkane synthase

In order to identify the enzyme responsible for hydrocarbon synthesis in microalgae, we undertook an approach of enzyme purification in C. variabilis. Following the observation that C. variabilis cells can convert exogenous fatty acids into alkanes or alkenes [START_REF] Sorigué | Beisson Microalgae synthesize hydrocarbons from long-chain fatty acids via a light-dependent pathway[END_REF], an activity assay for a hydrocarbon-forming enzyme was set up (fig. S1A). This discontinuous assay was sensitive enough to allow a partial purification of the protein responsible for the alkane-forming activity (fig. S1B). Proteomic comparison of three partially purified fractions resulted in a list of 10 common proteins, nine of which were homologous to well-characterized proteins (Fig. 1A). The most represented protein, and also the only one whose function was uncertain, was a member of the glucose-methanol-choline (GMC) oxidoreductases, a family of flavoproteins comprising a wide range of oxidases and dehydrogenases [START_REF] Cavener | GMC oxidoreductases. A newly defined family of homologous proteins with diverse catalytic activities[END_REF]. A full-length cDNA coding for the C. variabilis GMC oxidoreductase was cloned and found to encode a polypeptide of 654 amino acids (~69 kDa) (Fig. 1B). Expression in Escherichia coli of the corresponding codon-optimized synthetic gene (fig. S2) resulted in the production of C13 to C17 alkanes or alkenes (Fig. 1C), which demonstrated that this protein was indeed a hydrocarbon-forming enzyme.

Characterization of the fatty acid decarboxylase activity

To further characterize the activity of the C. variabilis GMC oxidoreductase, we expressed the recombinant protein in E. coli and purified it. Mass spectrometry analysis revealed the presence of a flavin adenine dinucleotide (FAD) cofactor (fig. S3), as observed in other characterized GMC oxidoreductases [START_REF] Cavener | GMC oxidoreductases. A newly defined family of homologous proteins with diverse catalytic activities[END_REF]. Characterization of the hydrocarbon-forming activity of the recombinant protein showed that this activity was optimum around pH 8.5 and decreased sharply when temperature rose above 35°C (fig. S3). No activity could be detected by using either a fatty acid methyl ester or a fatty aldehyde as substrate. In order to determine whether the reaction catalyzed by the alkane synthase was an actual decarboxylation of fatty acid, palmitic acid labeled with 13 C on the carboxylic group was used as substrate. Upon incubation of the substrate with the C. variabilis alkane synthase, production of 13 CO2 was detected at more than 20 times its natural abundance (Fig. 2A), thus indicating that the enzyme was a fatty acid decarboxylase. The purified enzyme was then tested on a wide range of free fatty acid substrates (C12 to C22) (Fig. 2B). All of them were converted into Cn-1 alkanes or alkenes, with a higher efficiency for C16-C17 chains. Saturated fatty acids were converted to alkanes, not alkenes, which showed that the C. variabilis fatty acid decarboxylase did not introduce a terminal double bond in the carbon chain, unlike the two fatty acid decarboxylases identified in bacteria [START_REF] Rude | Schirmer Terminal olefin (1-alkene) biosynthesis by a novel p450 fatty acid decarboxylase from Jeotgalicoccus species[END_REF][START_REF] Rui | Microbial biosynthesis of medium-chain 1-alkenes by a nonheme iron oxidase[END_REF]. We also identified a GMC oxidoreductase from C. reinhardtii with features and substrate specificities similar to its C. variabilis homolog (fig. S4).

Light-dependence of the C. variabilis alkane synthase

In algal cells, alkane formation requires light [START_REF] Sorigué | Beisson Microalgae synthesize hydrocarbons from long-chain fatty acids via a light-dependent pathway[END_REF]. The fact that the C. variabilis alkane synthase contains a chromophore, together with the observation that the purified enzyme does not require any additional cofactor to be active, prompted us to check the light dependency of the enzyme activity. We first observed that when the E. coli strain expressing the C. variabilis alkane synthase was cultivated under complete dark and never exposed to light, no hydrocarbon was produced (fig. S3G). Measurement of the activity of the purified C. variabilis enzyme at different wavelengths of visible light showed further that the alkane synthase was active in the presence of blue light (400 to 520 nm) (Fig. 3A). The action spectrum correlated with FAD absorbance, thus suggesting that FAD is the light-capturing part of the protein. However, these observations did not discriminate between a light-activated enzyme and a photoenzyme. The activity of the purified enzyme on 1-13 C-labeled palmitic acid was thus measured under different light conditions by monitoring the release of 13 CO2. We observed that 13 CO2 production started immediately upon illumination with blue light and stopped immediately after a shift to dark or red light (Fig. 3B). This demonstrated that the C. variabilis alkane synthase is a photoenzyme because it requires a continuous flux of (blue) photons for its activity. The same feature was also noted on the purified C. reinhardtii GMC oxidoreductase (fig. S4D). Alkane formation increased with light intensity (Fig. 3C). Using palmitic acid as substrate, we estimated the turnover number of the C. variabilis GMC oxidoreductase at 0.86 ± 0.13 s -1 under a fluence rate of 2000 μmol photons m -2 s -1 white light. The photoexcitation rate (supplementary materials, materials and methods) in this experiment was ~0.9 s -1 , indicating efficient photocatalysis (quantum yield >80%). On the basis of these results, we propose the name fatty acid photodecarboxylase (FAP) for the C. variabilis GMC oxidoreductase and its C. reinhardtiihomolog. The blue light dependency of the FAP prompted us to investigate the effect of the quality of light on the formation of hydrocarbons in algal cultures. When C. reinhardtii cultures were grown in photobioreactors under successively blue (<500 nm) and red (>600 nm) lights, alkane or alkene formation was correlated with the presence of blue light (Fig. 3D). This experiment thus showed that the light dependency of the FAP observed in vitro was relevant to living cells and likely to be related to its function in the cell.

Three-dimensional structure of the FAP

In order to gain insights into the structural basis of the light-dependent fatty acid decarboxylase activity of the C. variabilis FAP, we determined its three-dimensional (3D) structure in complex with a palmitate substrate (table S1). A crystal form diffracting to 3.15-Å resolution was obtained. Although the crystal was twinned, we were able to solve its structure via molecular replacement by using domains from two proteins of the GMC oxidoreductase family with known 3D structures (PDB codes 2JBV and 4YNT). The overall architecture of the FAP was similar to other GMC oxidoreductases, with a typical two-domain fold (Fig. 4A). The first domain, mostly shaped by N-terminal residues, stabilizes the FAD cofactor, whereas the second domain participates in substrate/product trafficking, with loops from both domains shielding the active site from the solvent and holding together both domains.

Fig.4 Structural features of the C. variabilis FAP. (A) Overall architecture of the enzyme in complex with FAD and palmitate (PLM). The structure is represented as an illustration colored from blue to red from the N to the C terminus, with the FAD and palmitic acid represented in stick. The long N-terminal helix is projected toward a noncrystallographic symmetry-related molecule that is not represented here for clarity. (B) Slice through the surface representation of the fatty acid photodecarboxylase. For clarity, small cavities in the interior of the enzyme are not shown. (C) Details of the palmitic acid-binding site with the side chains of residues within 4 Å of the substrate shown in stick. The omit map electron density associated to palmitic acid is also shown and contoured at 0.5σ (2Fo-Fc; blue) and 2σ (Fo-Fc; green). Single-letter abbreviations for the amino acid residues are as follows:

A, Ala; C, Cys; D, Asp; E, Glu; F, Phe; G, Gly; H, His; I, Ile; K, Lys; L, Leu; M, Met; N, Asn; P, Pro; Q, Gln; R, Arg; S, Ser; T, Thr; V, Val; W, Trp; and Y, Tyr. (D) Distances (angstroms) between palmitic acid and FAD.

The 3D structure of the FAP revealed a narrow hydrophobic tunnel, open to the solvent on one end and leading to the tricyclic ring of FAD on the other end (Fig. 4B). Electron density in this tunnel indicates the stabilization of a palmitate substrate that wraps around the side chain of Y466, with the carboxylate moiety interacting with the side chains of residues R451, C432, and Q486 (Fig. 4C) and pointing toward the FAD (shortest distance 3.7 Å) (Fig. 4D). The lower enzyme activity for medium-chain fatty acids (Fig. 2B) may be caused by a less efficient stabilization of short hydrophobic chains in the tunnel (especially around Y466). A multiple sequence alignment of GMC oxidoreductases of the FAP subgroup showed that most of the amino acids of the hydrophobic tunnel present in the vicinity of the FAD or lining the entry site of palmitate (vestibule) were conserved (fig. S5).

Role of FAD in the FAP photocycle

To elucidate the role of the FAD cofactor in the decarboxylation of fatty acids by FAP, we performed time-resolved optical spectroscopy measurements on the purified recombinant enzyme. The fluorescence kinetics (Fig. 5A) show that the substrate quenches the singlet excited state 1 FAD*, shortening its lifetime from τ ~ 5 ns (typical time constant for unquenched flavins [START_REF]Heelis The photophysical and photochemical properties of flavins (isoalloxazines)[END_REF] to τ ~ 300 ps. FAD-based reaction intermediates and kinetics were resolved by means of transient absorption spectroscopy on nanosecond to millisecond time scales. We presumed that the 300ps kinetics might reflect electron transfer (ET) from the substrate to 1 FAD*. Indeed, at 376 nm (where FAD •-absorbs more strongly than FAD) (Fig. 5B) an instantaneous (within the instrumental time resolution of 10 ns) absorbance increase was observed (Fig. 5C, black trace), whereas at 488 nm (where FAD •-absorbs less than FAD) (Fig. 5B), an initial bleaching occurred (Fig. 5C, blue trace). Measurements at other wavelengths confirmed the rapid formation of FAD •-(fig. S6, A andB). At most wavelengths studied, the initial absorbance changes decayed with τ ~ 100 ns (Fig. 5C and fig. S6A), indicating reoxidation of FAD •-to FAD. At 515 nm, however, the absorbance rose in ~100 ns (Fig. 5C, green trace) and decayed with τ ~ 4 ms (Fig. 5C,inset). Because the slope of the FAD absorption spectrum in FAP is steep at 515 nm (Fig. 5B), we considered the possibility that after reoxidation of FAD •-, the FAD spectrum was red-shifted because of a change in its environment resulting from the decarboxylation of the substrate. Spectral analysis of the 4-ms phase (fig. S6C) confirmed such a red-shift. In the absence of substrate, flash-induced absorbance changes show the formation of the FAD triplet state 3 FAD* (fig. S6, D andE), which is consistent with an intersystem crossing yield in the order of 70% for unquenched singlet excited flavins [START_REF]Heelis The photophysical and photochemical properties of flavins (isoalloxazines)[END_REF] and decay of 3 FAD* to ground state FAD in ~80 μs. In the presence of substrate, formation of 3 FAD* should be largely outcompeted by ET from the substrate to 1 FAD* in ~300 ps (fig. S6F), which is consistent with a high quantum yield of photocatalysis.

Fig.5 Characterization of C. variabilis FAP by means of time-resolved spectroscopy. (A) Time-resolved fluorescence of FAP in the presence or absence of palmitic acid. (B) Absorption spectra of FAD •-[in glucose oxidase (31); red line] and oxidized FAD in FAP (solid black line), scaled assuming a molar absorption coefficient of 11 300 M -1 cm -1 for the maximum of the absorption band in the blue (32). A red-shifted blue band of FAD in FAP (dotted black line) is shown to demonstrate the effect on the absorption at 515 nm. (C) Examples of transient absorption changes of FAP in

FAP clade in phylogenetic tree of GMC oxidoreductases

All members of the GMC oxidoreductase family characterized so far are oxidases or dehydrogenases (mostly acting on sugars), except some plant lyases that catalyze breaking of a C-C bond [START_REF] Dreveny | The hydroxynitrile lyase from almond: A lyase that looks like an oxidoreductase[END_REF] and the FAP, which is also a lyase. We analyzed the phylogenetic relationships of 50 prokaryotic and eukaryotic members of the GMC oxidoreductase family, including 20 proteins with demonstrated biochemical activities. C. variabilis and C. reinhardtii FAP did not group with the plant clade but instead belonged to a separate clade that contained only sequences from algae (Fig. 6, table S2, and fig. S7). This algal-specific clade included micro-and macroalgae and algae of primary or secondary endosymbiotic origin. Among the 22 algal species with sequenced genomes, 18 had a GMC oxidoreductase in the FAP clade. The four other algae (Ostreococcus and Micromonas species, from the same basal Mamiellophyceae class of green algae) lacked a predicted GMC oxidoreductase. Algal species with several GMC oxidoreductases were all of secondary endosymbiotic origin (such as Nannochloropsis, Phaeodactylum, or Emiliana). Thus, the algal clade of GMC oxidoreductases is likely to be a group with a conserved FAP function.

Discussion

Here, we identified a microalgal alkane synthase as a member of the GMC oxidoreductase family and a photoenzyme. Known enzymes with hydrocarbon-forming activity include oxidoreductases and polyketide synthases in cyanobacteria [START_REF] Schirmer | del Cardayre Microbial biosynthesis of alkanes[END_REF][START_REF] Mendez-Perez | Modular synthase-encoding gene involved in α-olefin biosynthesis in Synechococcus sp. strain PCC 7002[END_REF], fatty acid desaturase-like proteins CER1 and CER3 in plants [START_REF] Bernard | Joubès Reconstitution of plant alkane biosynthesis in yeast demonstrates that ArabidopsisECERIFERUM1 and ECERIFERUM3 are core components of a verylong-chain alkane synthesis complex[END_REF], cytochrome P450s in the bacterium Jeotgalicoccus sp. ATTC8456 and in insects [START_REF] Rude | Schirmer Terminal olefin (1-alkene) biosynthesis by a novel p450 fatty acid decarboxylase from Jeotgalicoccus species[END_REF][START_REF] Qiu | An insect-specific P450 oxidative decarbonylase for cuticular hydrocarbon biosynthesis[END_REF], and nonheme diiron oxidoreductases in the bacterium Pseudomonas aeruginosa [START_REF] Rui | Microbial biosynthesis of medium-chain 1-alkenes by a nonheme iron oxidase[END_REF]. Algal GMC oxidoreductases now join that group but have the added feature of being light-driven. Photoenzymes are an ancestral type of enzyme and may be rare because evolutionary selection has not favored light-driven catalysis [START_REF] Begley | Photoenzymes: A novel class of biological catalysts[END_REF]. Given the diversity of proteins able to perform synthesis of alkanes, light activation required by the chemistry seems unlikely. We therefore speculate that the light-driven nature of the microalgal alkane synthases is related to their function within the cell. The FAP function likely appeared after primary endosymbiosis, was kept during secondary endosymbiosis, but was lost in plants. Conservation of the FAP function in algae throughout evolution suggests a biological function specific to this group of organisms.

Because C. reinhardtii and C. variabilis FAP are active on various fatty acids in vitro, the formation in C. reinhardtii and C. variabilis cells of a predominant species of hydrocarbon (7-heptadecene) (18) may be due to the channeling of the precursor (cisvaccenic acid) to the FAP. This result suggests that the C. reinhardtii and C. variabilis alkane synthases interact with a yet-to-be-identified lipolytic enzyme that releases cis-vaccenic acid from a lipid or cofactor.

We propose a model of the FAP photocycle (Fig. 5D) that combines observed FADbased intermediates and kinetics (in red) with inferred (not directly observed) corresponding changes in the substrate. The FAD in FAP is first photoexcited (step 1). The singlet excited state 1 FAD* abstracts an electron from the fatty acid in ~300 ps (step 2). The fatty acid radical decarboxylates yielding an alkyl radical [step 3; not directly observed but analogous to the photo-Kolbe reaction [START_REF] Kraeutler | Bard Heterogeneous photocatalytic synthesis of methane from acetic acid -New Kolbe reaction pathway[END_REF]]. FAD •-transfers the electron back to the resulting alkyl radical in ~100 ns (step 4). Because of the extremely strong proton affinity of alkyl anions, we suppose that the ET is coupled to proton transfer from a proton donor XH (one of the neighboring amino acid residues or a water molecule). Alternatively, XH may transfer a hydrogen atom to the primary alkyl radical, followed by ET from FAD •-to X • in ~100 ns. We speculate that the resulting negative charge of X -may cause a red shift of the FAD absorption band in the visible. The FAD band shifts back to the blue in ∼4 ms (step 5), possibly because of reprotonation of X -. The alkane is released (step 6), and a new substrate is bound (step 7). Judging from the crystal structure, we considered the best candidates for XH would be cysteine C432 and tyrosine Y466 (Fig. 4C). In order to test our hypotheses about the involvement of a proton donor XH in the catalytic reaction, we have mutated these two residues to alanine, which should not be able to function as a proton or hydrogen atom donor. Although 50 to 60% of purified wild-type enzyme contained FAD, none of the mutant proteins bound the FAD cofactor. Thus, the hypothesis could not be tested.

Our identification of a photoenzyme acting on lipids shows that light-driven catalysis is not restricted to the processes of light capture and use or to the repair of UV damages in DNA. This discovery should thus provide an incentive to reinvestigate the activity of some enzymes involved in metabolic or signaling pathways regulated by light.

Fig. 1

 1 Fig.1 Identification of an alkane synthase in C. variabilis. (A) Number of proteins found after the final step in three independent purifications and list of the 10 proteins in common found by means of proteomic analysis. Proteins are ranked by decreasing spectral counts. (B) Predicted domains of the C. variabilis GMC oxidoreductase. (C) Chromatogram of the hydrocarbons produced (left) and immunoblot of the total proteins (right) in an E. coli strain expressing the C. variabilis GMC oxidoreductase (alkane synthase).

Fig. 2

 2 Fig.2 Fatty acid decarboxylase activity of the C. variabilis alkane synthase. (A) Relative quantification of 13 CO2 released upon incubation of 1-13 C-palmitate with the purified recombinant enzyme. S, substrate; E, enzyme. (B) Relative activity of the purified recombinant enzyme on various free fatty acid substrates. Mean ± SD (n = 3 repeats).

Fig. 3

 3 Fig.3 Light dependency of the C. variabilis alkane synthase. (A) Absorption spectrum and action spectrum of the purified enzyme. Mean ± SD (n = 3 repeats). The position of the flavin absorption maximum in the enzyme (467 nm) deviates from typical values (445 to 450 nm for most flavoproteins and free flavins). (B) Activity of the purified enzyme under successive light conditions. Activity on 1-13 C-palmitate was monitored via release of 13 CO2 by using membrane inlet mass spectrometry. (C) Dependence of the activity of the purified enzyme on white light intensity. Mean ± SD (n = 3 repeats). (D) Variation of total hydrocarbons in C. reinhardtii cells grown in a photobioreactor under blue and then red light. Mean ± SD (n = 3 repeats). FAMEs, fatty acid methyl esters.

  Fig.5 Characterization of C. variabilis FAP by means of time-resolved spectroscopy. (A) Time-resolved fluorescence of FAP in the presence or absence of palmitic acid. (B) Absorption spectra of FAD •-[in glucose oxidase (31); red line] and oxidized FAD in FAP (solid black line), scaled assuming a molar absorption coefficient of 11 300 M -1 cm -1 for the maximum of the absorption band in the blue (32). A red-shifted blue band of FAD in FAP (dotted black line) is shown to demonstrate the effect on the absorption at 515 nm. (C) Examples of transient absorption changes of FAP inthe presence of excess substrate. Complementary data are shown in fig. S6. (D) Suggested model of the FAP photocycle. Directly observed intermediates and kinetics are shown in red.

Fig. 6

 6 Fig.6Unrooted phylogenetic tree of the GMC oxidoreductase family. The neighbor joining method was used. Species are abbreviated to three letters (one for the genus and two for the species epithet) (tableS2). Proteins with demonstrated biochemical activity are indicated by three additional capital letters: AAO, aryl alcohol oxidase; AOX, alcohol oxidase; FAP, fatty acid photodecarboxylase; CBQ, cellobiose dehydrogenase; CHD, choline dehydrogenase; COX, cholesterol oxidase; CKO, compound K oxidase; FDH, fructose dehydrogenase; FOX, fructose oxidase; GDH, glucose dehydrogenase; GOX, glucose oxidase; HFO, hydroxy fatty acid oxidase (genetic evidence only); HNL, hydroxynitrile lyase; and POX, pyranose oxidase.

Acknowledgments:

We thank J. Ohlrogge for critical reading of the manuscript. Thanks are also due to V. Cardettini, A. Beyly, I. Té, P. Auroy, A. Beynel, J. Alric, C. Sahut, D. Lemaire, and F. Carrière for technical help or discussions. This work was supported by grants from L'Agence Nationale de la Recherche (ANR) (MUSCA ANR-13-JSV5-0005 to Y.L-B. and A*MIDEX ANR-11-IDEX-0001-02 to G.P.), the European Union (EU) (Sun2Chem project of ERASynBio), the French Infrastructure for Integrated Structural Biology