Jordane Lorandel
email: jordane.lorandel@cyu.fr

Mohamed Amine Khelif
email: mohamed-amine.khelif@cyu.fr

Olivier Romain
email: olivier.romain@cyu.fr

A Low-cost Hardware Attack Detection Solution for IoT Devices

Keywords: Security, Hardware Attack, I2C, FPGA, IoT

Hardware security becomes a major concern for the development of future IoT devices. In this paper, we propose to investigate traffic monitoring for a low-cost real-time anomaly detection for IoT. This solution relies on the characterization of the wired communication traffic occurring at the interface of the IoT devices, to detect potential attacks and abnormal behaviour by an intrusive solution. A specific hardware architecture is presented and evaluated in an experimental study, showing the effectiveness of the traffic modeling and the detection against two types of hardware attacks performed on the I2C bus.

I. INTRODUCTION

In the context of the Internet of Things (IoT), a lot of small connected devices is dispersed in the environment enabling the development of smart applications in many domains, starting from smart homes/buildings, e-health, smart farming, and industrial process control, autonomous vehicle, etc. These objects are able to sense, process data depending on their own capability and functionality. In 2020, for the first time, the number of IoT connections has exceeded the number of non-IoT connections (smartphones, laptop) [START_REF] Lueth | State of the iot 2020: 12 billion iot connections, surpassing non-iot for the first time[END_REF], revealing the current massive deployment of IoT devices. Around 31 billion of devices is expected by 2025, which is almost 4 devices per person in the world [START_REF] Lueth | State of the iot 2020: 12 billion iot connections, surpassing non-iot for the first time[END_REF].

However, it has been shown that most of the communications generated by these devices are still not encrypted [START_REF]More than half of iot devices vulnerable to severe attacks[END_REF]. More than half of them may reveal major vulnerabilities. In fact, these vulnerabilities could result from the embedded software itself, a misconfiguration, or a hardware weakness. Such vulnerabilities could be potentially exploited by an attacker and in the worst case, the integrity or the confidentiality of user data can be compromised. In some cases, an attacker could take control of the device itself to deploy on top of it a botnet [START_REF] Mcmillen | A new botnet attack just mozied into town[END_REF]. This idea is presented as the Internet of Vulnerabilities (IoV) in [START_REF] Angrishi | Turning internet of things(iot) into internet of vulnerabilities (iov) : Iot botnets[END_REF].

Starting from this observation, security has become a major concern for all the actors. In fact, the design of IoT devices was preliminary guided to meet typical constraints of embedded systems such as a limited memory capacity, short battery life, and small computing power. The security aspect of these objects appears to be often neglected or secondary.

For the last decade, many attacks have been realized on different target devices, that were categorized as software, hardware, and protocol attacks in [START_REF] Khelif | Toward a hardware man-in-the-middle attack on pcie bus[END_REF]. This reveals many remaining challenges to ensure a high level of security. In particular, hardware attacks are very difficult to prevent and could allow an attacker locating sensitive data or taking control of the system. For this type of attack, an assumption is that the attacker has physical access to the device, which seems reasonable regarding the massive deployment of IoT devices. For the future design of these devices, new security solutions have to be thus created with respect to the embedded constraints.

Generic hardware architecture of a typical IoT node is illustrated in Figure 1. As it can be seen, it mainly consists of a sensing unit, a processing part, a radio-frequency transceiver, a power management unit, and a memory. All these elements are interacting together, using different communication standards e.g. I2C, SPI, or UART. This device can be further customized depending on the final application. Such an architecture reveals many possible attack vectors for an attacker including wired communication protocols, wireless connectivity chips, memories, etc. In this paper, we focus on the hardware security vulnerabilities targeting widely used communication standards used in many IoT nodes, and more particularly I2C. In fact, this type of communication standard is essential in IoT devices to ensure data exchange between the different chips that compose the IoT device. For instance, the I2C bus could be used to exchange data between the sensing and the processing units or between the processing unit and an external chip. Despite the fact that this technology is very common, it represents a real opportunity for an attacker for gathering particular information about the system, for penetrating the system by creating a fault on the protocol, or by injecting special frames. Moreover, this bus is more vulnerable in comparison to other protocols as an attacker could simply plug his malicious device on the pull up resistors, without being more invasive. In parallel, no specific mechanisms are usually deployed to improve the security of the communication interfaces, in particular when considering small IoT devices based on low-cost micro-controller.

CPU or

¡C

The key contribution of the paper consists in proposing the preliminary element towards the development of an embedded low-footprint security monitoring circuit that allows real-time detection of hardware attacks targeting the wired communication interface used in small IoT devices. To better illustrate the interest of the approach, the solution is evaluated by performing typical hardware attacks on the I2C bus such as frame injection and heart bleed [START_REF] Khelif | Non-invasive i2c hardware trojan attack vector[END_REF]. This paper is organized as follows. First, Section II presents the different categories of hardware attacks with a focus on attacks targeting wired communication buses. Then, the attacks on I2C proposed approach and the low-level implementation details for the real-time attack detection block based on traffic characterization are presented in Sections III and IV respectively. Finally, real experiments of attack on I2C bus are given in Section V and discussed in Section VI before the conclusion.

II. RELATED WORKS

From the last decade, many types of attacks have been performed on IoT devices, showing many vulnerabilities and security issues. Among them, hardware attacks represent a particular category of interest as they are very challenging and expensive to counter. However, they are generally more difficult to perform in comparison to software and protocol attacks since they require prior knowledge of the system and its behaviour through a reverse engineering phase [START_REF] Khelif | Toward a hardware man-in-the-middle attack on pcie bus for smart data replay[END_REF]. In this section, we focus on hardware attacks and more particularly the ones targeting common wired communication buses.

Hardware attacks include attacks that can be qualified as either passive or active. Considering passive attacks, they require neither opening the chip package nor modifying the IoT device. Instead of that, they consist in measuring the variation of electromagnetic radiation, power consumption, timing execution, temperature, or other metrics of interest from the target device to leak information [START_REF] Persial | Side channel attack-survey[END_REF]. Side channelattack is one of the most used passive attacks.

When considering an active hardware attack, the attacker could choose to perform a hardware modification of the chip or to target an external interface of a communication bus.

Several communication protocols represent a potential attack surface. For instance, USB [START_REF] Lau | Mactans: Injecting malware into ios devices via malicious chargers[END_REF], I2C [START_REF] Gomez-Bravo | Hardware attacks on mobile robots: I2c clock attacking[END_REF], JTAG [START_REF] Vishwakarma | Exploiting jtag and its mitigation in iot: a survey[END_REF], UART [START_REF] Gupta | The IoT Hacker's Handbook[END_REF], CAN [START_REF] Levy | CAN-LOC: spoofing detection and physical intrusion localization on an in-vehicle CAN bus based on deep features of voltage signals[END_REF] and SPI [START_REF] Asmita-Jha | IoT Security -Part 15 (101 -Hardware Attack Surface : SPI)[END_REF] can be physically accessed from any available pins of the devices without any modification.

The I2C bus is one of the most popular serial communication buses. It is an open protocol that makes serial communication between many peripherals easy. However, it is also simple to disrupt communications within this bus. As presented in [START_REF] Gomez-Bravo | Hardware attacks on mobile robots: I2c clock attacking[END_REF], the I2C bus attacked using a clock glitching approach. During the attack, the I2C clock line (SCL) is forced to low while communication between a master and a slave peripheral occurs. This allows a malicious attacker to prevent the master to send its message to its selected slave. However, the attacker has to generate acknowledgments to the master instead of the initial target slave in order to not drive the bus to a fault state and to let the master believes that the transaction is effective. As countermeasure, the authors suggest a clock frequency sensor to detect variation in SCL.

In [START_REF] Bojovic | The rising threat of hardware attacks: Usb keyboard attack case study[END_REF], a key-logger attack was demonstrated over the USB. This attack permits to record and transmit all the data that are exchanged over the bus. It also allows to write and modify data. This work shows how it is easy to recover passwords or confidential data using this attack.

Other works have attacked the UART bus with the objective of accessing firmware or sensitive data stored into a component. This information is then used to find and exploit security vulnerabilities that will allow a more complex and potentially damaging attack to be carried out [START_REF] Gupta | The IoT Hacker's Handbook[END_REF]. This is because the UART bus is used in the majority of devices in the IoT as a port for diagnostics and debugging. Also, the UART port is generally poorly protected which makes the attack not very difficult to undertake.

As for the UART bus, the SPI bus is mainly used for attacks that aim to recover data and firmware [START_REF] Asmita-Jha | IoT Security -Part 15 (101 -Hardware Attack Surface : SPI)[END_REF]. The biggest constraint of the SPI bus is that there is no fixed configuration and the number of wires (slave select) depends on the number of components connected to it, except if a daisy chain approach is realized.

The Controller Area Network (CAN) bus is a widely used standard in automotive and industrial applications which allows secure communications with a high level of error detection and a strong electromagnetic protection. However, it is still possible to implement a hardware trojan on this bus as shown in [START_REF] Bozdal | Hardware trojan enabled denial of service attack on can bus[END_REF]. In [START_REF] Levy | CAN-LOC: spoofing detection and physical intrusion localization on an in-vehicle CAN bus based on deep features of voltage signals[END_REF], a CAN bus monitoring approach with detection and localization of attacks is proposed as a counter-measure. The solution is based on machine learning and demonstrates a very high accuracy up to 100% for the detection of intrusion and frame injection and 98% for replacement scenarios. However, this approach necessitates to have a large dataset available and seems inappropriate to fit on small IoT devices.

Another type of hardware attack relies on fault injection in order to perturb the chip behaviour and to leak secrets. They require either to be able to interface the target chip in a non-conventional way or the decapsulation of the chip without altering its die. It can be passive if the attack is performed on power and clock lines [START_REF] Martin | Fault attacks on strngs: Impact of glitches, temperature, and underpowering on randomness[END_REF]. More invasive attacks are possible on the depacked device/chip by modifying memory content of RAM, cache, EEPROM, or NVM using laser, UV beams or electromagnetic waves [START_REF] Eslami | A survey on fault injection methods of digital integrated circuits[END_REF]. As demonstrated by [START_REF] Khelif | Toward a hardware man-in-the-middle attack on pcie bus for smart data replay[END_REF], not only external interface can be the target of attacks. Indeed, internal communication data buses, even high-performance ones such as PCIe can be interfaced to extract information passively using a sniffer approach or actively by using a Man-in-the-Middle approach.

Despite the panel of possible hardware attacks on serial communication buses, some solutions have already been proposed to enhance IoT device security. For example, a coprocessor called SPI-Nooper [START_REF] Hossain | Spi-snooper: a hardware-software approach for transparent network monitoring in wireless sensor networks[END_REF] is in charge of monitoring internal SPI communications between a processor and its radio-frequency transceiver in a Telo mote. It also allows to log traffic, check data integrity and perform abnormal behaviour detection. Other solutions based on cryptography to encrypt data stored into external memory chips could mitigate most hardware attacks. However, cryptography consumes a lot of power and memory resources and is not necessarily used in IoT devices. Moreover, even if the data exchanged on the communication bus are encrypted, the other fields used by the communication protocol are generally not encrypted (target slave address in I2C, the header of PCIe packet, etc.). From this observation, many innovative security solutions could be developed on top of this source of information, essential in the implementation of the communication protocol.

III. ATTACK ON THE I2C INTERFACE A. I2C protocol

I2C is a widely used protocol in the industry for interconnecting multiple elements together using only on two signals, SCL and SDA for clock and signal respectively. Based on a Master/Slave communication scheme, the master always imposes the communication to the different slaves on the bus and is in charge of generating the clock signal, the start of the packet and the end of the packet by driving the lines to low or releasing them to one. A 7-bit/10-bit addressing field allows a master to select a slave while a read/write bit permits to define the type of request [START_REF] Irazabal | i2c manual" application note[END_REF]. The selected slave can only answer the master with the request data and by sending acknowledgement (ack/nack) bits.

Many attacks such as sniffing, heart bleeding and buffer overflow can be performed on this bus as presented in [START_REF] Khelif | Non-invasive i2c hardware trojan attack vector[END_REF]. In case of heart bleeding attack, the attacker needs to force the ack/nack bit to low in order to avoid the negative acknowledgment that normally stops the memory request. This allows an attacker collecting more information than expected but could also generate an error on the Master side. In addition, an attacker can perform an I2C frame injection to retrieve particular information from the slaves connected to the bus. If the attacker is able to perform a time analysis of the system, malicious frames could be injected without occurring error on the bus or triggering security mechanisms.

B. Discussion and positioning

I2C represents an interesting surface attack vector due to its massive use in IoT devices. Many devices with diverse complexities are concerned going from simple connected lights to the most advanced ones like smartphones or Raspberry pi. Even if I2C is often dedicated to low throughput communications due to its simplicity, it is also widely used as a data bus between a processor or micro-controller and its memories. For instance, Apple's iPhones, iPads, and MACs are currently using the I2C bus between their Secure Enclave chip and an EEPROM memory in which sensitive data such as the password attempt counter and the secure boot are stored [START_REF] Apple | ios security ios 12[END_REF]. As a consequence, this bus would represent an interesting source of information for an attacker. Developing security solutions that are able to detect an attack or an anomaly in real-time at low cost, remains a challenge, especially when dealing with the low power requirements of very small IoT devices. Even if statistical or machine-learning solutions have proven to be effective on widely used buses [START_REF] Levy | CAN-LOC: spoofing detection and physical intrusion localization on an in-vehicle CAN bus based on deep features of voltage signals[END_REF], there is still a lack of solutions for very small IoT devices.

IV. REAL-TIME TRAFFIC MONITORING AND CHARACTERIZATION

A. Modeling of I2C traffic

The traffic generated inside a chip or at its interface can provide many information about the behaviour of the system itself. Indeed, in case of attack, such as a botnet, the amount of traffic exchanged on the communication buses would significantly increase in comparison to normal behaviour. It is thus of further importance to be able to characterize the traffic in order to design a solution allowing the detection of a potential attack or anomaly on the device. From this observation, we propose to compute and collect specific metrics to model the behaviour of a traffic at low implementation cost. The defined metrics are computed from specific information obtained from fields related to the communication protocol, such as the number of write requests, number of bytes per frame, etc. We explain this choice because this type of information can be obtained on top of any communication protocol and works even if the raw data are encrypted.

In our study, the following metrics were defined to characterize the I2C traffic: In order to develop algorithmic solutions that could exploit these metrics and to make easier the characterization of the traffic over the time, we measure and average them on a user-defined time window. Note that the raw data can also be logged and processed offline in order to retrieve additional information such as the number of slaves, number access per slave, number of R/W requests, etc. This only necessitates a sniffer device or logic analyzer. Many solutions are available off-the-shelf such as Analog Discovery 2 Kit from Avnet. In addition, one can note that the considered metrics are voluntarily kept as generic as possible in order to let the possibility of characterizing many other wired communication protocols such as SPI, CAN, etc. In addition, bus-specific metrics could also be easily integrated.

B. Low-level Hardware Architecture

To compute the metrics defined in the previous sub-section, a hardware IP was designed. The low-level details about the hardware implementation are given by Figure 2.

The solution relies on an I2C slave interface that allows logging all the traffic exchanged on the bus without perturbing the communication. To this purpose, SCL/SDA input pins are configured in high-state mode. As it can be seen, the I2C lines are then sent to two modules, a traffic logger and a metric calculation core. For these 2 IPs, external AXI-Stream interfaces were chosen to permit AXI4-compliant connections with other standard IPs and a fast design development. For instance, the outputs of these IPs are connected to AXI-Stream FIFOs from Xilinx. These FIFOs allows to transfer the logged data and the computed metrics to the processor through AXI4-Lite Interfaces. Regarding the software design, the processor is polling the empty signal of the different FIFOs to get both the raw data or the metrics. The processor could either output the metrics through a UART to an external PC or also performs some additional processing directly on the metrics if needed.

From a practical point of view, the interfacing of this solution to the I2C bus under characterization could be easily performed by soldering wires on the pull-up resistors of the target device, after a reverse engineering phase to retrieve their localization. This also demonstrates that an independent and external traffic characterization solution could be added to a small IoT device without redesigning or perturbing it.

Another particularity of the solution is the possibility to select the sampling frequency of the metrics, respectively the duration of the time window. A 2-bit signal named (SW) allows the selection of the duration between 1ms, 0.01s, 0.1s and 1s. A typical clock of 100MHz has to be provided at the corresponding input to generate the multiple clock frequencies.

V. TRAFFIC MODELING AND DETECTION OF ATTACK

To validate our solution, we developed an experimental setup based on an MCP9808 sensor, a Nucleo-F446RE and an E2PROM memory, all interconnected through an I2C bus.

The application running on the Nucleo-F446RE, acting as Master, consists in getting the temperature from the MCP9808 every second and then writing the results to the external E2PROM memory. The corresponding setup is illustrated in Figure 3. The solution for traffic characterization was implemented onto a Zedboard platform from Avnet [START_REF] Avnet | Zedboard zynq-7000 platform[END_REF], which includes a Zynq-based SoC device, combining an FPGA-based programmable logic (PL) and a dual-core Cortex-A9 processor as the programmable system (PS). In our case, the PL side implements the IP while the PS is used to control the logic, configure the time window and send the results of the traffic analysis to an external PC through UART.

The implementation resources used by the IP are summarized in Table I. As it can be seen, the overall solution is using very few logic and memory resources with respect to the FPGA device available on the Zedboard platform, respectively 7% of LUT, 5% of Flip-Flops and 5 BRAMS. Note that 5 AXI-Stream FIFOs are required in total for collecting both raw data and the defined metrics.

During this experimental setup, we recorded the considered metrics for several minutes and for different scenarios. In the first scenario, no attack is generated on the system. The expected behaviour is the normal one, regarding the metrics. For the second scenario, we developed another architecture onto an FPGA device, to perform a frame injection attack on the I2C bus. Two malicious frames will be injected at different times without generating any error on the bus or perturbing the application. In the third scenario, a heart bleeding attack was realized in a similar way as in [START_REF] Khelif | Non-invasive i2c hardware trojan attack vector[END_REF].

Figure 4 gives the corresponding histograms obtained for the T BF (Time Between Frame) metric, considering an analysis time of around 2 minutes for each scenario. As it can be seen, T BF metric provides enough information for detecting an abnormal behaviour of the system with respect to the 2 attacks performed. For instance, we observe a dispersion of the T BF values due to the frame injection attack in comparison to the two distinct areas in the normal behaviour.

Regarding the heart bleeding attack, the number of T BF values close to 0 significantly increases in comparison to the normal case. This is expected because, for this type of attack, the communication between the master and its slave is altered. Indeed, the ack/nack bit of the master is forced to low by the attacker, meaning that the target transaction is not finished and the slave (the E2PROM memory in our case) keeps sending packets to the attacker that maintains the communication by generating a clock on the SCL line. In our solution, the metric calculation core does not update the value of the T BF as the end of the transaction does not appear. Recall that this type of attack allows an attacker to retrieve more information as needed, for example, the content of additional memory addresses.

Regarding another metric such as the measurement of the duration of valid I2C frames (expressed in clock cycles), the detection of the attack can also be observed as illustrated by Figure 5. For a frame injection attack, the histogram reveals the emergence of additional frame duration due to the new frames injected by the attacker. The detection of the heart bleeding attack is also visible, as for the previous metric, with the apparition of many values close to 0. The same conclusion could be drawn when studying complementary metrics offered by the design, such as N bByte, N BF rame and N bAckN ack.

VI. DISCUSSION AND ANALYSIS

The characterization of the traffic seems well adapted for systems that exhibit periodic tasks. We believe that most of the applications targeting small IoT devices are dedicated to periodic sensing processing and transmission of data. The traffic generated on the communication buses should remain roughly the same, even if the periodicity is changed, making this solution well adapted.

As previously mentioned, other solutions for attack detection exist such as evolved statistical and machine learning techniques [START_REF] Levy | CAN-LOC: spoofing detection and physical intrusion localization on an in-vehicle CAN bus based on deep features of voltage signals[END_REF] but they still remain very complex to realize and require a high computing power that is not necessarily available on small IoT devices. The prototype made in this project was firstly developed on FPGA but the used resources could be significantly optimized with an ASIC implementation.

The solution proposed in this paper corresponds to the first element of the security block with the detection of the attack. A further analysis would be the classification and/or identification of the type of attack by studying the behaviour of the defined metrics. Moreover, as many built-in sensors are available in small IoT devices, an interesting approach would be to jointly combine the recording of metrics related to the communication part with non-functional ones e.g. the device's temperature or power consumption.

Another interesting opportunity is the use of low-complexity algorithms in combination with this hardware design to develop a real-time anomaly detection solution. In particular, online anomaly detection algorithms have proven to perform well as online estimators [START_REF] Skaperas | Real-time video content popularity detection based on mean change point analysis[END_REF] against DDoS attacks. The proposed design would be the first element of a self-monitoring security solution that will assess an abnormal behaviour in real-time and low-cost.

VII. CONCLUSION

In this paper, we present the first element toward the design of low-cost real-time anomaly detection for IoT devices. The solution relies on the characterization of the wired communication traffic occurring at the interface of the IoT devices, to detect potential attacks. A specific hardware architecture is presented, showing the low footprint of the solution which makes it compatible to be embedded with small IoT devices. A successful detection of two hardware attacks targeting the widely used I2C bus was demonstrated. The future works will focus on demonstrating the genericity of the approach on other IoT communication buses in combination with online estimators.

Fig. 1 .

 1 Fig. 1. Simplified IoT hardware device architecture.

Fig. 2 .

 2 Fig. 2. Hardware Architecture for Traffic logging and Metric Calculation on I2C.

•

  T BF : Time between successive frames • AT : Time of each active frame • N bByte: Number of exchanged byte • N bF rame: Number of frame • N bAckN ack: Number of ACK and NACK bits

Fig. 3 .

 3 Fig. 3. Validation setup for the I2C Traffic Analysis.

Fig. 5 .

 5 Fig. 5. Histogram of the Active T ime metric for the 3 scenarios.

TABLE I HARDWARE

 I RESOURCE UTILIZATION ON A ZEDBOARD PLATFORM.

	Description	LUT Flip-Flop BRAMS
	Metric Calculation + clock Management	398	654	0
	Traffic Logger	60	83	0
	AXI-Stream FIFOs (x5) 362	357	1
	Total (%)	7	5	5

  Histogram of the time between f rame metric for the 3 scenarios.

	Number of sample	0 50 100	0	0.2	0.4	0.6	0.8	1 No Attack	1.2	1.4	1.6	1.8	2
							Sample value				×10 8
	Number of sample	0 50 100	0	0.2	0.4	0.6 Frame Injection Attack 0.8 1 1.2 1.4	1.6	1.8	2
							Sample value				×10 8
	Number of sample	0 50 100	0	0.2	0.4	0.6	0.8 HeartBleeding Attack 1 1.2	1.4	1.6	1.8	2
							Sample value				×10 8
	Fig. 4.


Mohamed Amine Khelif
email: mohamed-amine.khelif@ensea.fr

Jordane Lorandel
email: jordane.lorandel@ensea.fr

Olivier Romain
email: olivier.romain@ensea.fr

Experimental interfacing with the IPhone 6s through its PCIe communication bus

Keywords: Hardware security, Man-in-the-Middle, PCIe, smartphones, Apple iPhone

One of the issues to perform hardware attacks on wired communication protocol is the physical access to the bus. Considering the iPhones, PCIe is used as a communication bus between the SoC and its non-volatile memory. This communication can be targeted by a MitM attack in order to access personal information. In this paper, we propose a physical way of interfacing between the motherboard and the non-volatile memory of an iPhone 6s. This was achieved by reverse-engineering the memory in order to retrieve the footprint and the pinout, defining a protocol to safely extract and resolder the memory, without altering its content, and multiple tests to validate the approach. The results obtained allow us to consider the fabrication of an interposer in order to realize a real hardware MitM and to exploit a large possibility of attacks such as real-time data analysis, data-replay, shadow-copy, and so on.

I. INTRODUCTION

Mobile Phones, and in particular Smartphones are widely adopted, with 6.4 Billion users worldwide in 2021 [START_REF] Statista | Number of smartphone users from 2016 to 2021[END_REF]. These devices became a part of our life, as used as a daily companion, keeping our personal information such as messages, photos, agenda, and more.

In iPhones for example [START_REF] Apple | ios security ios 12[END_REF], the non-volatile memory contains all the user's personal data as well as critical security data such as encryption keys or the password attempts counter. Usually, the stored data is encrypted by a dedicated cryptocore in the SoC.

All this information including user and security data is exchanged through communication buses making access to such content a real threat, even if the communication is encrypted. In the state of the art, there are some hardware attacks targeting internal communication buses of smartphones or IoT devices such as USB [START_REF] Lau | Mactans: Injecting malware into ios devices via malicious chargers[END_REF], I2C [START_REF] Khelif | Non-invasive i2c hardware trojan attack vector[END_REF] or even Apple's proprietary bus used until iPhone 6 [START_REF] Skorobogatov | The bumpy road towards iphone 5c nand mirroring[END_REF]. Since the iPhone 6s, Apple has started to use PCIe as the communication protocol between the Processor and the non-volatile memory express (NVMe).

Thus, our approach consists of implementing a hardware MitM attack on this particular type of communication bus. The other advantage is that MitM can be performed on any iPhone or device using PCIe as a communication bus with the requirement to adapt the hardware interface to the targeted device. The considered hardware attack is one of the less exploited in the state of the art, while it is very promising as it is the only one that allows direct access to data and, in addition, offers a wide attack vector possibilities including data replay, traffic analysis, and data corruption.

MitM

Memory CPU

Fig. 1. Man-in-the-Middle principle [START_REF] Khelif | Toward a hardware man-in-the-middle attack on pcie bus[END_REF].

In [START_REF]Toward a hardware man-in-the-middle attack on pcie bus for smart data replay[END_REF] and [START_REF] Khelif | A versatile emulator of mitm for the identification of vulnerabilities of iot devices, a case of study: smartphones[END_REF], a versatile hardware MitM architecture capable of interfacing with PCIe and three practical MitM attack scenarios was presented: packets log and filter, packets log and corruption, and shadow copy of all the data transmitted through the PCIe bus in real-time. These scenarios were developed and tested on FPGA used as a smartphone emulator. After this, work the remaining question is: how to Physically interface a MitM FPGA between the SoC and the memory of an iPhone 6s?

Apple uses in these iPhones many proprietary chips that are specially developed for its devices. In order to perform a hardware-based MitM attack on the PCIe bus, it is essential to obtain as much information about the target as possible and validate its accuracy through testing. To make the hardware MitM possible, the following challenges appear:

• Define a protocol to safely unsolder and solder the memory, without altering its content. • Recreate the footprint and the pinout of the memory chip.

• Analyze the impact of an interposer on iPhone operating.

• Define the specifications for the interposer daughterboard, to be compliant with both the smartphone and our FPGA board.

II. PRELIMINARY WORK In order to interface with PCIe bus, we will need to perform preliminary works on the motherboard and reverse-engineering the Memory.

A. Memory Footprint and Pinout

Here we will show the logical process followed to recreate Apple's NVMe VLGA U1500 chip under Eagle software through the realization of the footprint and pinout of the chip from information at our disposal.

Footprint: Due to the size of the chip and in order to be able to measure as accurately as possible, several methods exist based on cameras or binoculars. In our case, we used an X-ray tomography with manual measuring tools, which allowed us to have approximate measurements but still enough precision to obtain the following results.

Pinout: Apple's iPhone 6s uses an NVMe memory chip U1500 (70 pads) according to the VLGA standard derived from the LGA standard (Land Grid Array). There are 3 manufacturers supplying Apple with these chips: Toshiba, Sandisk, and SKhynix. In the naming convention of the pads [START_REF] Open | Flash interface specification[END_REF], there are several types of LGA chips but none corresponds to the chip used by Apple and which must be certainly a proprietary fingerprint. However, the pinout must respect the standard of LGA pin naming. Also in the LGA chip standard [START_REF] Open | Flash interface specification[END_REF], the 52 pads chip is the closest to the iPhone 6s VLGA chip. It has the same positioning of the pads for those present and gives an idea of how the convention works. The pins are assigned to the fingerprint according to their coordinates present in the schematics. In the case of the iPhone 6s, the unofficial schematic is available online and contains the NVMe memory schematic.

The measurements obtained by X-ray tomography and the pinout defined make possible the creation of a chip in Eagle software. A new library has been created for the Apple NVMe VLGA U1500 memory which contains the schematic of the component, the PCB footprint, and a device file that allows linking the schematic to the footprint in order to have the pinout represented on the PCB.

Two PCBs were made in order to be able to do the first tests, to validate the measurements of the footprint and the pinout, and also to have an estimation of the resiliency for adding extra lines of a few centimeters to the existing data PCIe line. The PCBs are two-layer with metalized vias. As the objective of these PCBs is to perform preliminary tests and for tools limitations we restricted ourselves to only two layers PCBs and we did not take into account the length of the lines for the same differential pair since the main objective here is not to recover the PCIe packets but just the validation of the reverse engineering performed. The first PCB we made is composed only of metalized vias and has the same size as the NVMe chip. The main purpose of this PCB is to elevate the memory footprint on the mother board above the surrounding passive components, thus making easier the positioning of larger PCBs. The second PCB is a flexible one that is responsible for transferring communication signals between NVMe and the motherboard such as power supply signals, clock lane, and a PCIe lane (RX0 and TX1) in order to validate the feasibility of our approach. It will be positioned between the memory and the first PCB.

III. TEST INTERPOSER

Now the objective is to define a precise, reliable, and reproducible protocol for unsoldering and resoldering the memory and/or deporting it without damaging it or altering the stored data.

A. Memory extraction and insertion

Memory extraction: For protecting the components of their smartphones, Apple encloses them with an underfill that is solid at room temperature and soft at high temperatures. This underfill is notably present on the passive components around the memory as well as between the memory and the motherboard. This underfill must first be removed using a scalpel and hot air tool at 250 • C before unsoldering the memory. Otherwise, it is highly probable that components at the edge of the memory will be pulled out during the NVMe chip extraction. Several tests were also performed to remove this underfill with chemicals. However, the most efficient solution is to use hot air to soften it and then gradually cut with a scalpel into the space between the memory and the components around it. When the underfill around the memory is removed, it is possible to unsolder the chip without the risk of damaging other components. However, because of the presence of underfill also between the memory and the motherboard that holds it in place, it is required to apply a leverage force on the component when the tin is fully melted.

To do this, it will be necessary to define the right heating temperature and exposition time to extract the memory. A too high heating temperature and/or a too localized at one point and the pads will melt (may also damage the memory or its content), a too low heating temperature, not uniform, and/or not long enough and the pads will be ripped off.

Re-solder the memory: In order to be able to solder the memory on its motherboard, it will be necessary to first re-ball the chip with tin. For this purpose, it is possible to use specific stencils, which are specially designed for a chip. In our case, we used a more general method which is manual reballing. This method with a bit of experience allows us to have an equivalent result, with a homogeneous amount of solder on all the pads. It will be necessary to use a hand hot air gun to heat as homogeneously as possible the component previously positioned on the motherboard while applying a slight vertical pressure to hold it in place. Once the soldering is done, an Xray tomography was systematically done to check the quality of the contacts and the absence of short-circuits due to an excess of tin.

Interposing a PCB : Two incremental tests were carried out to validate the possibility of interposing a PCB without altering the communication between the board and the NVMe. Figure 2 shows how the first PCB was integrated between the memory and the motherboard. We used two tins with different melting temperatures in order to realize this manipulation. Finally, this PCB adds 2 mm distance between the NVMe and the motherboard and the smartphone still works perfectly. The second version consists of the addition of the first PCB and the flex PCB between the memory and the motherboard of the iPhone 6s. Ideally, three tin temperatures should be used to integrate the PCBs into the smartphone. In our case, we only had access to two temperatures so the flexible PCB is a better solution in comparison to a rigid one. The result is shown in Figure 3. The welds are checked by X-ray tomography in order to validate that the contacts have been properly realized. Once this part is completed, the smartphone is booted to check if it is still functional and that there is no overheating due to potential short circuits. As you can see on Figure 4, The iPhone starts normally and apparently without loss of data due to our interposer.

IV. MEASUREMENTS RESULTS

To measure the signals that are transferred using our interposer, we used the best oscilloscope available to us: a Teledyne LeCroy WaveMaster 804Zi-B 4GHz with three ZD1000 1GHz active differential probes. The active differential probes prevent adding perturbations to the communication while connecting to the data lanes. Neither the oscilloscope nor the differential probes go high enough in frequency to allow a proper acquisition of PCIe signals.

Even if the recovered signals are not usable, we can still validate the pinout performed since we got the right power supply values, clock reference signal, and PCIe lane on each pad. With Figure 5, we can see that the clock is activated just before communication, which is coherent with the behavior of memories in smartphones in order to save battery life. We can also see that the frequency of the PCIe bus reference clock on the iPhone 6s is 24MHz, which is lower than on computers, defined at 100MHz.

V. WORK IN PROGRESS MITM INTERPOSER

The objective is to develop an electronic card allowing the interception of PCIe communications for passive analysis (Sniffing) or active processing of communication on the fly (MitM). This interface will be composed of a flexible PCB that will be placed between the NAND chip and the motherboard of the iPhone 6s, and a daughter-board that will be connected to the smartphone via the flexible circuit. The daughter-board will be in charge of carrying out the necessary processing to allow the FPGA board to be interfaced. 6 illustrates the setup to interpose an FPGA between the memory and the iPhone motherboard. To do this, we will use a KZT socket that will reconnect the memory to the motherboard using pogo pins instead of resoldering it. A flexible PCB will be in charge of redirecting the signals to the daughter-board that will take in charge the signal conditioning and routing to 2 PCIe gen3 x16 ports. Finally, the FPGA will be connected to the daughter-board using their PCIe ports and will be in charge of realizing the MitM and the different scenarios developed as in [START_REF]Toward a hardware man-in-the-middle attack on pcie bus for smart data replay[END_REF] [8] [START_REF] Khelif | Hardware man-in-the-middle attacks on smartphones[END_REF]. In this case, it is an Intel Stratix 10 MX Development kit, which embeds 2 PCIe ports gen3 x16 as the daughter-board.

The Flex PCB locally connects all power supplies and transfers all signals including power supplies to a robust and high performance (15.5 GHz/ 31Gbps) SAMTEC ST4 60 point connector. The Flex uses the footprint and pinout realized during the reverse engineering phase. All the signals go back and forward on it except the power supply signals. This will allow switching between sniffer and MitM mode.

The Daughter-board ensures the isolation of the smartphone from the motherboard and affects all the signals to test points. The necessary control signals are sent to the FPGA. PCIe signals are routed according to the positioning of dedicated switches. This allows having both sniffer and MitM modes with the same daughter-board. In sniffer mode, the signals are looped back after the reception buffers. These buffers are used to transfer a copy of the signal to the FPGA, without altering the communication between the processor and the memory. In MitM mode, the lanes from the processor (RootComplex) are simply routed to the Root connector on the board. Signals coming from the memory are routed to the EndPoint connector. This configuration will permit to have the FPGA physically located between the memory and the SoC meaning that all the PCIe communication traffic is going through the FPGA.

The first versions of the daughter-board and the flex circuit are currently being manufactured.

VI. PERSPECTIVES AND FUTURE WORKS

With this MitM setup, we will be able to study the PCIe communications in real-time with more evolved algorithms which is impossible for now due to the lack of information. The information obtained through the sniffer mode will be used to create a dataset of iPhones communications between the SoC and the NVMe chip. With this dataset, we will be able to perform offline analysis of the communication between the CPU and the memory especially during the boot phases and during password updates. Performing this statistical analysis will show us the low occurrence events that could be related to the password attempts counter (limit of 10 attempts in iPhones) and help to locate more or less precisely the sensitive data in the memory. Other methods of information mining have to be investigated and compared in order to determine the best approach that can be done for our case of study: offline analysis or online analysis. Especially online methods, which will be more efficient if the location of the counter in memory is modified at each update. The hardware implementation of these algorithms on the FPGA target is also a challenge especially knowing the performance that must be achieved by the architecture to perform on the fly analysis with respecting PCIe protocol constraints. On the other hand, the MitM mode will be used to test and validate the attacks developed in previous works [7] [8] [10] such as traffic analysis, data replay, and a new approach that we propose and which is based on Intel's shadow copy technology. This hardware MitM will give us access to a large attack vector that could make possible locating sensitive data or security mechanisms from the iPhones 6s.

VII. CONCLUSION

In this article, we discussed the problem of the physical interfacing of a MitM between the NAND chip and the motherboard of an Apple's iPhone 6s. An entire methodology of reverse engineering was done. It consists of creating the memory pinout and the footprint of the iPhone 6s proprietary NAND, defining a reproducible, reliable, and precise methodology to extract safely the memory. Moreover, several test PCBs were manufactured in order to validate the feasibility of the approach. These steps allowed us to prove the possibility of interfacing and transferring PCIe lanes without corrupting the behavior of the smartphone during the boot process and after. This, let us suppose the good integrity of the communication between the NAND and the SoC, even with the interposer. These tests, also permit obtaining more information about the clock frequency of the iPhone 6s PCIe bus. The final step of this work consists of the MitM interposer which is already developed for its first version and is currently being manufactured. The advantage of this method and the development that we are doing is that recent iPhones still use the same technologies and our approach can be applied easily to more recent devices at the expanse of designing a new flexible PCB to adapt to the considered chip.

Fig. 2 .

 2 Fig. 2. iPhone 6s NVMe elevation using custom PCB.

Fig. 3 .

 3 Fig. 3. iPhone 6s NVMe signal deportation using custom PCB.

Fig. 4 .

 4 Fig.4. iPhone 6s with a test interposer between the motherboard and its memory.

Fig. 5 .

 5 Fig. 5. Clock and data signals recorded from a real smartphone.

Fig. 6 .

 6 Fig. 6. Illustration of the MitM setup.

Figure

  Figure6illustrates the setup to interpose an FPGA between the memory and the iPhone motherboard. To do this, we will use a KZT socket that will reconnect the memory to the motherboard using pogo pins instead of resoldering it. A flexible PCB will be in charge of redirecting the signals to the daughter-board that will take in charge the signal conditioning and routing to 2 PCIe gen3 x16 ports. Finally, the FPGA will be connected to the daughter-board using their PCIe ports and will be in charge of realizing the MitM and the different scenarios developed as in[START_REF]Toward a hardware man-in-the-middle attack on pcie bus for smart data replay[END_REF] [8][START_REF] Khelif | Hardware man-in-the-middle attacks on smartphones[END_REF]. In this case, it is an


Ayman Akhdar

Sophie Faure

Arnaud Gautier

Arylopeptoid oligomers functionalised by combinatorial

or sequential on-resin click chemistry using a copper(I)-N-heterocyclic carbene catalyst

Arylopeptoid oligomers functionalised by combinatorial or sequential on-resin click chemistry using Copper(I)-N-heterocyclic carbene catalyst

Ayman Akhdar, a Sophie Faure* b and Arnaud Gautier* b Efficient on-resin click chemistry protocol using Copper (I)-Nheterocyclic carbene catalyst, a stable source of Cu(I), is developed for post-functionalization of N-alkylated aminomethylbenzamide oligomers (arylopeptoids). The accessibility to a panel of polyfunctionalized N-substituted aromatic oligoamides by solidphase synthesis is demonstrated using combinatorial and sequential approaches.

N-alkylated aromatic oligoamides is a class of oligomers still underexplored. 1 Contrary to other aromatic oligoamides relying on hydrogen-bonding networks for their structuration, 2 the conformational modularity and adaptability of N-substituted aromatic oligoamides make them particularly interesting abiotic oligomers for applications in the medical and/or materials field. 1 One major issue for their development is the ability to provide welldefined sequences with high chemical diversity. To this aim, Nsubstituted aminomethylbenzamide oligomers are particularly well adapted and represent particularly promising aromatic oligoamides. 3 They were named arylopeptoids 4 since their backbone can be considered as the peptoid (N-substituted glycine oligomer) [START_REF] Kline | Sequence-Controlled Polymers[END_REF] backbone in which a phenyl group is inserted (Figure 1). Sequencedefined arylopeptoids are accessible via solid-phase submonomer method wherein each residue is created in two steps: acylation/substitution [START_REF] Hjelmgaard | [END_REF] or acylation/reductive amination. 7 The submonomer method potentially provides access to highly diverse structures. 8 Another way to introduce chemical diversity is the postfunctionalization of formed oligomers. This strategy is particularly attractive in the context of multivalent display 9 and has never been studied to access functionalised arylopeptoid oligomers. Therefore, click chemistry and especially the CuAAC reaction which was introduced two decades ago by Kolb, Finn and Sharpless, could be of particular importance as it is modular and high yielding. From the point of view of the synthetic chemist, combinatorial synthesis on solid support allows the rapid preparation of large and organized collections of compounds (molecular libraries) which constitute an essential source in drug discovery. [START_REF] Herlan | For a review on combinatorial chemistry of peptoids[END_REF] Nevertheless, CuAAC on solid support requires sometimes large amount of copper catalyst that is difficult to remove and therefore could contaminate the samples. 11 Also, several drawbacks from ascorbic acid has been reported (dehydroascorbate reacts with amines, lysine and arginine). 12 Moreover, some sensible functional groups are damaged by the hydroxy radicals that are produced by the reaction of Cu(I) and oxygen. 13 Therefore, copper(I)-N-heterocyclic carbenes (Cu-NHCs) that are recognized as stable source of Cu(I) offer great opportunities in this field. Indeed, several publications from our group report applications in the peptide field. 14 Here, we report the application of [SIMesCu(4,7 Cl-Phen)Cl] as CuAAC catalyst to the on-resin construction of an arylopeptoid library. To examine the possibility of post-functionalisation of metaarylopeptoid oligomers by 'on support' click chemistry process, we started our investigation by reacting benzyl azide (Ia) with synthesized resin-bound hexamer II-6(Alk3,6) containing four isopropylamine and two propargylamine side chains (Scheme 1; see ‡ for the nomenclature). This model reaction was studied on four different resins; three polystyrene-based resins: 2-chlorotrityl chloride, Rink Acid and Rink Amide, and one (polyethylene glycol)based resin: trityl-OH ChemMatrix®. The Rink amide resin providing oligomers with a primary amide in C-terminal (X = NH) and the others leading to oligomers with an acid function (X = O). First, the hexamer II-6(Alk3,6) was prepared on the various resins using published protocols (ESI for details). [START_REF] Hjelmgaard | [END_REF] We used [SIMesCu(4,7Cl-Phen)Cl] ‡ ‡ in a mixture of methanol and dichloromethane (2/8) to keep a good swelling of the resin in presence of a proton source that is essential for the catalysis. In these conditions, the outcome is strongly dependant of the type of resin. A total lack of reactivity was observed using 2-chlorotrityl resin with 20 mol-% catalyst or more as demonstrate by the recovery of the hexamer II-6(Alk3,6) in 95% yield after cleavage. In addition, the colour of the solution stays reddish, even after 24h, suggesting that the catalyst is not destroyed. Using trityl-OH ChemMatrix® resin (20 mol-% catalyst), a total conversion to III-6(a3,6) takes place at room temperature after 16h.

Scheme 1. Model reaction to study the on-resin click chemistry process

However, HPLC-mass spectroscopy proved that the products consist in a mixture of mono-and double-clicked compounds in a ratio 7/3. Increasing the temperature to 50°C allows to obtain a total conversion of the two propargyl groups after 2h. Regardless the temperature, in all cases a 50% purity measured by HPLC was observed after cleavage, hampering the use of the trityl-OH ChemMatrix® as solid support. Using Rink acid resin and performing the CuAAC reaction at 50°C during 3h, we were pleased to obtain full conversion and acceptable crude HPLC purity (>70%) for III-6(a3,6) (X = O) but in low yields (ranging from 20 to 50%). We also noticed that the reaction colour turns rapidly from red to greenish, suggesting a fast destruction of the catalyst and the production of copper(II). By analysis of the reaction mixture and the washing solvent, we found that partial cleavage of the arylopeptoid oligomer occurred during the click step, explaining low yields obtained. Decreasing the temperature to RT doesn't improve the results (80% conversion after 18h but cleavage from the resin still occurring). Thus, we concluded that a partial cleavage occurs (either due to the Lewis acidity of Cu II or the small amount of HCl realized in the media by the catalyst) competitively with the CuAAC reaction. From these first tests, the CuAAc reaction using copper(I)-N-heterocyclic carbene [SIMesCu(4,7Cl-Phen)Cl] proved to be difficult to efficiently access functionalised arylopeptoid oligomers with a C-terminal acid group. By contrast, using Rink Amide resin, we were delighted to find a lack of cleavage, a total conversion to III-6(a3,6) featuring a C-terminal primary amide (X = NH) with good reproducibility, crude purity (84%) and yield (85%) after 5 hours at room temperature using 20 mol-% catalyst (Figure 2). Importantly, the solution stays reddish, suggesting a good stability of the catalyst. At 50°C, we were also able to decrease the reaction time to 1 h without alteration of yield and purity and reach the same results using only 1 mol-% of catalyst after 7 h. For comparison, the more classical conditions 15 using CuI catalyst (5 mol%) in presence of ascorbic acid (8 mol-%) and Hünig base (15 mol-%) in DMF/piperidine (7/3) at 50°C affords a low conversion (30%) to an equimolar mixture of mono-and bis-triazole after 3h. We were glad to obtain good yields and purities regardless the number and the position(s) of the alkyne(s) (table 1). In all cases, a total conversion was observed by LCMS associated with good crude purities. Therefore, a large range of functionalized triazoles could be introduced efficiently at different positions of the arylopeptoids. In order to increase the chemical diversity, we have explored the possibility to build a small combinatorial library. A major issue in this field is to obtain a homogeneous distribution of the products. Therefore, we estimate the relative reaction rate of the different azides Ia-e in solution toward propargyl alcohol, as depicted in Scheme 3, using microcalorimetry. Interestingly, the completion versus time curves present all a sigmoid shape, the alcohol Ie being the more reactive and the protected acid Ic the less. This shape is consistent with the one obtained when the reaction presents a non-classical kinetics, due to either a slow generation of the active catalyst or an activation by the product. To determine if the reaction is activated by the product, we compared the reaction of benzyl azide with propargyl alcohol in solution in or presence of a small amount of triazole product (15 mol-%, Scheme 4). The addition of 15 mol-% of the product produces a decrease of the inductive period and an increase of rate, typical of an activation by the product. This observation is important to build our combinatorial library because it suggests that a reaction can be accelerated by the product of another one that occurs faster and simultaneously. Therefore, the products repartition will not reflect the rates anymore. This was confirmed by measuring the amount of each product after reaction the amine Id and alcohol Ie with the supported II-4(Alk2,4) using 5 mol-% of catalyst (Figure 3). After cleavage, we observe the presence of the four products (identified by LC-MS) in comparable amount determined by HPLC (28, 25, 24 and 19% area), demonstrating that no strong preference occurs. Therefore, couples of azides from the pool Ia-e were selected for building the combinatorial libraries from resin-bound tetramer II-4(Alk2,4) and hexamer II-6(Alk2,4,6) containing two and three alkynes respectively. The combination should afford n m possible compounds (where n: number of azides and m: number of alkynes), thus four and eight different oligomers are expected. As shown in Table 2, total conversions were observed with good isolated yields and purities.

For entries 1-5, as expected, a mixture of four arylopeptoids were obtained, containing two identical triazoles and two positional isomeric compounds identified by LC-MS. For entries 6-10, HPLC separable signals were obtained. However, difficult separation was sometime obtained giving peaks overlapping. respectively (comparison with authentic samples, Table 1). The regioisomers containing two acids/one benzyl or two benzyl/one acid respectively were identified (LC-MS and HPLC) as two distinct subsets (retention times of 41-43 and 47-50 minutes, respectively). This points out the problem of the identification of a specific compound from a mixture of regioisomers. Therefore, a sequential approach was developed to access oligomers with various triazoles at well-defined positions. Thus, the oligomer should continue to grow-up on the solid support after click reaction. We performed a back synthesis of III-4(d2,e4) and III-4(e2,d4) (Figure 3) and all the regioisomers of III-6(a,c)(2,4,6) appearing between 40-50 minutes (Figure 4). For the tetramers, two synthetic pathways were explored (scheme 5). Path A starts with III-3(Alk2) which was clicked with Id.

We were pleased to see that elongation occurs efficiently to afford III-4(d2,Alk4). Final post-functionalization using 1e affords the expected product (82 % yield, 92% HPLC purity). Path B describes the synthesis of the second regioisomer which occurs by i) cycloaddition with 1e, ii) elongation, iii) CuAAC with Id and iv) cleavage. III-4(e2,d4) was obtained in 79% isolated yield (87% HPLC purity) for 11 steps. Interestingly, elongation occurs on the alcohol III-3(e2) without any side reactions (i.e. esterification). In conclusion, we report for the first time the use of Cu(I)-NHC for poly-functionalisation by CuAAc reaction on resin. This efficient and mild process performed on rink amide resin-bound oligomers with a panel of azides was applied to access a small library of functionalized meta-arylopeptoid trimers, tetramers and hexamers. To increase the chemical diversity, a combinatorial approach was efficiently developed. Finally, a sequential approach has enabled the synthesis of specific oligomers containing various triazole groups at welldefined positions demonstrating the versatility of this on support click chemistry process using [SIMesCu(4,7Cl-Phen)Cl] as catalyst.

Notes and references

Figure 1

 1 Figure 1 Analogy between peptoid and arylopeptoid oligomeric structures.

Figure 2 .

 2 Figure 2. HPLC chromatogram at 220 nm of crude III-6(a3,6).In view of these results, to continue this work we decided to use only Rink Amide resin-bound oligomers and to perform on support CuAAc reaction with 5 mol-% of [SIMesCu(4,7Cl-Phen)Cl] as catalyst at 50°C in presence of four equivalents of azides per alkyne. Using these optimized conditions, a set of functionalized azides (Ia-e) were tested on II-3(Alk2), II-4(Alk2,4) and II-6(Alk2,4,6) resin-bound oligomers (Scheme 2). The collection of azides contains benzyl (Ia), cyclohexyl (Ib), tert-butyl carboxylic ester (Ic), Boc-protected amine (Id), and alcohol (Ie) groups.

Scheme 3 .

 3 Scheme 3. Completion vs time for azides Ia-e in solution.

Scheme 4 .

 4 Scheme 4. Completion vs time in presence of 0 or 15 mol-% of added product

Figure 3 .

 3 Figure 3. HPLC chromatogram at 220 nm showing repartition of products III-4-(e,d)(2,4).

Figure 4

 4 depicts the eight diversely functionalised arylopeptoids III-6(a,c)(2,4,6) (entry 7). The first and last were identified as III-6(c2,4,6) and III-6(a2,4,6)

Table2.a

  Combinatorial CuAAc on resin-bound II-4(Alk2,4) or II-6Double bracket notation refers for all positional isomers. ‡ b Purity determined by analytical HPLC.

Figure 4 .

 4 Figure 4. 220 nm HPLC chromatogram at 200 nm of III-6(a,c)(2,4,6).

  ‡: I stand for azides, II for resin-bound arylopeptoid oligomers containing alkyne(s) and III for arylopeptoid oligomers containing triazole(s). A single bracket notation stands for a single regioisomer, i.e. III-3(a2) refers to a trimer containing a benzyl triazole at position 2. Notation with two brackets refers to a mixture of compounds from combinatorial library, first bracket stands for the triazole's substituents and the second for the positions. ‡ ‡: SIMes: 1,3-Bis(2,4,6-trimethylphenyl)-4,5-dihydroimidazol-2ylidene; 4,7Cl-Phen : 4,7-dichloro-1,10-phenanthroline.

Table 1 :

 1 Clicked arylopeptoid from II

-3(Alk2), II-4(Alk2,4) and II-6(Alk2,4,6)

	III-4(e2,4)	98	97
	III-6(a2,4,6)	78	88
	III-6(b2,4,6)	76	91
	III-6(c2,4,6)	67	95
	III-6(d2,4,6)	70	93
	III-6(e2,4,6)	82	98
			Arylopeptoid	Isolated yield (%)	Isolated purity (%) a
			III-3(a2)	98	98
			III-3(b2)	85	85
			III-3(c2)	97	96
			III-3(d2)	85	97
			III-3(e2)	90	99
			III-4(a2,4)	85	87
			III-4(b2,4)	75	95
			III-4(c2,4)	85	81
			III-4(d2,4)	77	95

a Purity determined by analytical HPLC.