Panagiotis Ilia
email: panagiotis.ilia.2011@my.bristol.ac.ukg.oikonomou

George Oikonomou

Theo Tryfonas
email: theo.tryfonas@bristol.ac.uk

Cryptographic Key Exchange in IPv6-Based Low Power, Lossy Networks

Keywords: 6LoWPAN, Key Exchange, ECC, ECDH

The IEEE 802.15.4 standard for low-power radio communications defines techniques for the encryption of layer 2 network frames but does not discuss methods for the establishment of encryption keys. The constrained nature of wireless sensor devices poses many challenges to the process of key establishment. In this paper, we investigate whether any of the existing key exchange techniques developed for traditional, application-centric wireless sensor networks (WSN) are applicable and viable for IPv6 over Low power Wireless Personal Area Networks (6LoW-PANs). We use Elliptic Curve Cryptography (ECC) to implement and apply the Elliptic Curve Diffie Hellman (ECDH) key exchange algorithm and we build a mechanism for generating, storing and managing secret keys. The mechanism has been implemented for the Contiki open source embedded operating system. We use the Cooja simulator to investigate a simple network consisting of two sensor nodes in order to identify the characteristics of the ECDH technique. We also simulate a larger network to examine the solution's performance and scalability. Based on those results, we draw our conclusions, highlight open issues and suggest further work.

Introduction

Wireless Sensor Networks (WSNs) consist of a large number of autonomous devices that cooperate to collect important data and send them through wireless communication channels to a base station or a data centre. Every node mainly consists of a microcontroller, a memory unit, a transceiver, a power source and one or more sensing elements. Due to their nature, wireless sensors are very constrained in terms of available RAM, speed of computation, network bandwidth and battery lifetime.

In 2003, the IEEE published the first version of IEEE 802.15.4, a specification for the physical and link layer operation for low-power radio communication. Initial research efforts suggested that TCP/IP was not viable for WSNs and that bespoke, application-centric network stacks were more suitable [START_REF] Estrin | Next century challenges: Scalable coordination in sensor networks[END_REF][START_REF] Hill | System architecture directions for networked sensors[END_REF].

However, the release of uIP demonstrated that standards-compliant TCP/IP stacks for embedded devices are viable [START_REF] Dunkels | Full TCP/IP for 8-bit architectures[END_REF]. Subsequently, it was shown that a TCP/IP-based WSN could outperform traditional, application-centric network designs [START_REF] Hui | IP is dead, long live IP for wireless sensor networks[END_REF]. As a result, a series of Internet specifications have been suggested for the transmission and routing of datagrams with IPv6 over Low power Wireless Personal Area Networks (6LoWPANs) [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802[END_REF].

With 6LoWPAN, WSN nodes with IEEE 802.15.4 radio transceivers are directly accessible from the Internet and are exposed to a host of security threats. Modern sensor devices are often equipped with an encryption/decryption coprocessor and link layer frames can be transmitted encrypted with the 128-bit Advanced Encryption Standard (AES) algorithm. However, there are challenges associated with key management and the process of key exchange in 6LoWPANs is not trivial. On many occasions, keys are individually pre-loaded to the nodes, which can be characterized as an important security vulnerability.

In this paper, we investigate whether any of the existing techniques for dynamic generation and exchange of cryptographic keys are applicable and can be adopted for 6LoWPANs. We argue that techniques based on Elliptic Curve Cryptography (ECC) [START_REF] Miller | Use of Elliptic Curves in Cryptography[END_REF] are very promising and we implement an Elliptic Curve Diffie Hellman (ECDH) shared key generation and establishment algorithm. This mechanism is also responsible for the management of existing encryption keys, searching and returning them to the link layer when requested, or starting the key exchange process if two neighbouring nodes do not have a shared secret key. It additionally handles key storage, expiration and replacement.

We implemented the key management mechanism and ECDH algorithm for the Contiki embedded operating system 1 and we evaluated it in terms of applicability, viability and scalability with network size and density. We evaluate memory footprint for a single node as well as how the number of stored keys affects network scalability. In addition, we use the Cooja simulator to conduct several simulations and assess node energy consumption, network lifetime and performance.

Background

Key management schemes proposed for WSNs are divided mainly into two different categories: i) symmetric key schemes where the keys are either pre-installed or assigned by a trusted party and ii) schemes based on Public Key Cryptography (PKC).

Symmetric Key Schemes

Compared to PKC, symmetric key schemes have the advantage that they are less computationally intensive, requiring fewer micro-controller instruction cycles to perform the calculations required for encryption and decryption. Keys are pre-installed during the network's deployment and initialization phase and neighbouring nodes discover and establish a shared key during the network formation phase [START_REF] Zhang | Wireless sensor network key management survey and taxonomy[END_REF].

Among existing efforts is a key exchange approach which requires the existence of a trusted party in the WSN, acting as a Key Distribution Centre (KDC), a role which can be assumed by a Base Station (BS) [START_REF] Roman | Key management systems for sensor networks in the context of the Internet of Things[END_REF]. In this scheme the KDC must establish a secure, single-hop communication channel with every node of the network, in order to deliver the secret keys. The trusted entity-based key exchange scheme cannot be applied in 6LoWPANs because the assumption that all nodes are within a single hop of the base station does not always hold true: The aim of 6LoWPAN and related specifications is to facilitate the formation of multi-hop networks [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF].

A different approach relies on each node having a pre-installed set of keys chosen from a key pool. These schemes can be either deterministic or probabilistic. Under deterministic schemes, every node is capable of establishing a pair-wise key with all its neighbors. One method that stands out is the one proposed in [START_REF] Yener | Combinatorial design of key distribution mechanisms for wireless sensor networks[END_REF], whereby every two nodes in the network share exactly one common key. According to Bechit et al., deterministic schemes do not scale well with network size [START_REF] Bechkit | A Highly Scalable Key Pre-Distribution Scheme for Wireless Sensor Networks[END_REF] and are thus unsuitable for 6LoWPANs where scalability is a desirable feature.

Under probabilistic schemes, a common key is present between two neighbors with some probability. For instance, under the scheme documented in [START_REF] Eschenauer | A key-management scheme for distributed sensor networks[END_REF], a small subset of k keys is chosen randomly out of a large key pool S. Every network node exchanges the identifiers of its keys with its neighbors and, if a common key exists, it is used as their session secret key. A more contemporary probabilistic scheme is the one proposed in [START_REF] Bechkit | A Highly Scalable Key Pre-Distribution Scheme for Wireless Sensor Networks[END_REF]. Because of the probabilistic nature of such schemes, many pairs of nodes do not share a common secret key and thus, they try to find a secure routing path through their neighbors in order establish it. If the connectivity of the network graph is not high, it is possible that the network becomes partitioned into sub-networks and thus it may be impossible to discover paths for key establishment between the two parts. Since full network connectivity is not guaranteed, such schemes are unsuitable for 6LoWPANs [START_REF] Roman | Key management systems for sensor networks in the context of the Internet of Things[END_REF]. Additionally, if a single node is compromised a large subset of the global key pool may be revealed to the attacker [START_REF] Bechkit | A Highly Scalable Key Pre-Distribution Scheme for Wireless Sensor Networks[END_REF]. However, because keys are pre-installed, revocation and replacement is not trivial.

Public Key Cryptography

Public key schemes are more demanding in terms of computation and energy consumption than symmetric key schemes. However, Zhang and Varadharajan argue that public key schemes provide a higher level of security, they scale better with network size and they have lower storage requirements [START_REF] Zhang | Wireless sensor network key management survey and taxonomy[END_REF].

The classic Diffie Hellman algorithm uses keys of very large size and does not provide any authentication mechanism, unless used alongside other protocols. It is reported that the RSA encryption algorithm is viable in WSNs despite using a large key [START_REF] Wang | Efficient Implementation of Public Key Cryptosystems on Mote Sensors[END_REF][START_REF] Gura | Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs[END_REF][START_REF] Wander | Energy analysis of public-key cryptography for wireless sensor networks[END_REF]. The advantage of RSA over Diffie Hellman is that it can provide both key exchange and authentication with a single pair of keys (publicprivate). However, the processes of key generation and encryption (for secret key establishment) are still very slow and energy consuming.

Elliptic Curve Cryptography (ECC) is a very attractive solution for 6LoW-PANs, since key length is considerably smaller than that used by other traditional PKC schemes. Consequently, according to NIST recommendations, the strength of a 160-bit ECC key is equivalent to a 1024-bit RSA key [START_REF] Barker | Recommendation for key management part 1: General (revision 3)[END_REF].

Reportedly RSA and ECC cryptosystems with 1024-bits and 160-bits key size respectively have been implemented on MICA motes and PKC is a feasible security solution for sensor networks [START_REF] Wang | Efficient Implementation of Public Key Cryptosystems on Mote Sensors[END_REF]. Additionally, software implementations of RSA and ECC public-key algorithms exist for Atmel AVR Atmega128 microcontrollers [START_REF] Gura | Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs[END_REF], which is a hardware platform commonly encountered in 6LoWPAN deployments. It is observed that the 160-bits ECC is not only much faster than the equivalent 1024-bits RSA, but it also uses less memory for data and code hosting. The authors of that work extend their research by implementing RSA key exchange with mutual authentication as well as ECDH with ECDSA, between two non-trusted parties [START_REF] Wander | Energy analysis of public-key cryptography for wireless sensor networks[END_REF]. They discuss a simplified and lightweight Secure Sockets Layer (SSL) protocol in order to allow sensor nodes to perform a handshake and subsequently to negotiate and establish a secret key. Energy consumption for a full handshake with ECC is four times lower than with RSA.

Bianchi et al. introduce the asymmetric scheme of Identity Based Cryptography (IBC), which is based on bilinear pairings on elliptic curves, as a promising key exchange scheme for WSNs [START_REF] Bianchi | Flexible key exchange negotiation for wireless sensor networks[END_REF]. The IPC scheme was subsequently adopted for IP-based WSNs [START_REF] Mzid | Adapting TLS handshake protocol for heterogenous IP-based WSN using identity based cryptography[END_REF]. The fundamental idea of IBC is that every string, like the identity of each node (ID), can be used as a valid public key and thus the use of large certificates for authentication is avoided. By using this approach, nodes are able to establish a common secret key without any communication. However, the main drawback stems from the fact that private keys are computed only by the trusted authority (TA) by using the ID of the each node and its secret key. If a particular key is leaked, the TA must pick a new secret key and start a re-keying phase.

Implementation of the Key Exchange Technique

We implemented the ECDH key exchange technique for the Contiki OS, which is a portable and lightweight operating system, specifically designed for use by devices with limited resources. The Contiki OS supports a full TCP/IP network stack, including support for a host of standard internet protocols, such as IPv6, UDP, TCP, ICMP and HTTP. It also implements the 6LoWPAN adaptation layer as defined in IETF's Request For Comments (RFC) 4944 [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802[END_REF] and the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF].

Link Layer Frame and Framer

Our proposed key exchange solution is implemented as a daemon process and underpins the network stack's secure link layer frame transmission by establishing secret keys for symmetric encryption between single-hop neighbor nodes. Contiki's implementation of IEEE 802.15.4 Medium Access Control (MAC) frame generation and parsing does not currently support the security header specified by the IEEE 802.15.4 standard. We have modified the respective code module to support the generation and parsing of the security header in a standardscompliant fashion. If the application determines that the MAC frame needs to be secure (by defining the security bit in the frame control field), the security header is appended to the address field of the MAC header, prior to the data payload. The link layer frame generation module accepts outgoing frames from the layer 2 driver, adds the MAC header at the beginning of each frame and delivers them to the radio transceiver's driver. It also receives incoming frames, parses and removes the MAC header and delivers the payload to the upper layers. Apart from the frame structure, we also modified the link layer framer to fill the values of the Auxiliary Security Header.

The link layer on the transmitting node queries our driver for the existence of a shared key with the intended recipient, identified by the frame's destination MAC address. We search our Access Control List (ACL) for an entry matching the destination MAC address and, if an entry exists, we return the established key as shown in Fig. 1. If the association is not in the ACL the frame is dropped due to the lack of security guarantees and an internal transparent process for key exchange starts.

Fig. 2 illustrates a state transition diagram for our key exchange daemon process. A device will spend most of its time in the Listening state. When the network stack attempts to transmit a frame, the node will transition to the Searching for the secret key state. Depending on the outcome of the key search, the daemon will either return a pointer to the shared key and revert to the Listening state or it will move to the Starting Key Exchange state.

ECC Implementation

In the current work, we used source code from the ContikiECC project [START_REF]Sustainable Computing Research (SCoRe) -ContikiECC[END_REF] in order to implement the basic elliptic curve operations. The ContikiECC project is a Contiki port of the TinyECC library [START_REF] Liu | TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks[END_REF]. It implements functions to handle very large numbers as multiple 8-bit or 16-bit words and provides the basic numerical operations for 8-bit and 16-bit microprocessors. Moreover, it provides a number of elliptic curves of sizes 128, 160 and 192 bits by specifying each curve's parameters and base point. As discussed above, modern sensor hardware platforms provide hardware acceleration for 128-bit AES encryption, hence our decision to use a curve of 128 bits for the construction of secret keys.

From the ContikiECC library, we use the basic large number operations to implement the ECC operations of point addition, point doubling and multiplication by a scalar multiplier. ECC operations are based on the sliding window method which provides more optimised characteristics in comparison to other methods.

In order to implement the Diffie Hellman algorithm over elliptic curves, each node creates an ephemeral private key as a random 128-bit number. By multiplying the private key with the elliptic curve's base point, we compute the node's public key. For the establishment of a shared secret key between two parties, each party multiplies its own private key with the public key received by the node it is negotiating with. Public keys are transmitted as clear text. A new private-public key pair is used for each negotiation.

For the generation of random numbers, we use Contiki's library which provides a platform-independent Application Programming Interface (API). Each platform supported by Contiki provides a hardware-specific Random Number Generator (RNG) implementation, which underpins this API. For instance, the cc2430 and cc2530 System-on-Chip (SoC) platforms provide hardware-based RNG implementations, while other platforms rely on software. In most cases, random bits from the Radio Transceiver's receive path are used to seed the RNG implementation.

Key Storage and Management

We construct a custom data structure (key association) that links the destination node's MAC address, the established secret key, key lifetime and the state of the key exchange procedure. The information remains stored in the structure until the shared key expires. After the shared secret has been established, the privatepublic key pair used to generate it is erased.

Every node in the network has a statically pre-allocated ACL table for storing key association data structures. Each key association has a lifetime (in seconds), which is set when the key establishment process is over. Every second, the daemon periodically enters the Purging Expired Associations state (Fig. 2) and decrements key lifetimes by one. When an entry's lifetime reaches zero the shared secret is erased, the MAC address is set to all zeros and the entry's state is reset. This releases the association, which can then be allocated for a new key establishment in the future.

At the beginning of the key exchange process the sensor node allocates a free ACL entry to store the new association in relation to the destination's MAC address. A special situation is the case where an entry is not completed but is already allocated, which means that another key exchange process is in progress (with different neighbor). By handling this situation we avoid the re-allocation of an already allocated association and we can support multiple concurrent key establishment negotiations.

The Key Exchange Process

The Diffie Hellman key exchange daemon is a background process, which remains idle as long as a key exchange is not requested. The process is transparent and application-independent.

The ECDH daemon is triggered if a secret key is requested by the network stack but does not exist in the ACL table. In order to start the key exchange process, the daemon first allocates a free ACL entry. It then queries the node's Neighbor Discovery (ND) cache to determine the IPv6 address of the destination node. If both steps are successful, the daemon computes the ECC private-public key pair and sends a key exchange request to the destination node over UDP.

We build a simple protocol for the key exchange messages, defining the Protocol Version, Message Type and Payload, which actually is the sender's public key. Reception of a key exchange request also triggers the ECDH daemon. Upon reception of an ECDH message, the receiving node first validates the protocol version and message type, as illustrated in Fig. 3.

If the message type is Request, it means that the sender node is asking for key exchange and sends its public key. Thus, the receiver allocates an ACL entry, creates its own ephemeral ECC keys, sends a Reply message, computes the secret shared key by performing elliptic curve point multiplication and sets the key lifetime. In this case, the daemon enters the states of Generating Private/Public Keys, Sending Public Key, Awaiting Response and Computing Secret Key in that order, as shown in the state transition diagram in Fig. 2. On the other hand, if the received message is a key exchange reply, the node searches to find the related ACL association and computes the secret shared key by using the data of the specific association entry and the received public key. To overcome the situation of an ACL association being permanently allocated because of indefinitely waiting for a key exchange reply message, we set a keyexchange timeout by setting the association's lifetime to a low value during the negotiation. After the temporary lifetime is initialized, it decreases periodically similarly to the secret key lifetime. If the key-exchange attempt expires, the allocated ACL entry is released and the daemon transitions from the Awaiting Response state to Listening.

Experimental Setup, Results and Analysis

We evaluate the key exchange technique with the Cooja simulator2 , which is distributed with the Contiki OS. Default parameters used for our experiments are provided in Table 1. Some experiments use different configuration parameters, in which case the modifications are clearly discussed in the text. Cooja can emulate motes at the hardware level, allowing precise inspection of system behavior. The sky platform is very commonly used and very well supported by Cooja and for that reason it has been chosen for our experiments.

Memory Requirements

The memory requirements of the key exchange technique are presented in Table 2. For implementing the ECDH key exchange method we use the 16-bit mode of ContikiECC's libraries (line nn in the table). Moreover, we use the Standards for Efficient Cryptography Group (SECG) standardized elliptic curve SECP128R1, by defining curve parameters a and b and its base point. The ecdh line relates to the ECDH daemon, which implements the ACL table, provides the key management mechanism and handles the process of key exchange.

Results show that we spend about 7.7 Kb of the device's ROM memory for source code hosting and about 1.1 Kb of RAM for storing curve parameters and ACL associations.

Latency, Average Energy Consumption and Network Scalability

The first and simplest experiment consists of only two nodes that communicate for a long time period so that many secret key re-establishments can take place. This experiment investigates energy consumption and computation times required for the calculation of public and secret shared keys as well as for a full key exchange process.

In this example, key exchange always begins with Alice, while Bob is always the node receiving Alice's request and has to reply. The communication is performed properly as long as the lifetime of the secret key has not reached the value of zero. When the secret key expires a new secret key must be established for further communication.

The time needed for the creation of the public key and the computation of the secret key, as well as the overall time for the key exchange process is given in Table 3(a). Table 3(b) presents the energy Alice and Bob consume to create their public key and the shared secret key. It also presents the overall energy consumption for the full key exchange process. To estimate energy consumption, we use Contiki's energest module. We measure the time each node spent in each of the following three states: i) Micro-Controller Unit (MCU) active, ii) RF listening / receiving (RX), iii) RF transmitting (TX). Since we are simulating sky motes, we then converted these time values to estimated energy consumption based on typical datasheet power levels at an operating voltage of 3.0V. Energy spent for the creation of the public and the secret key is calculated based solely on microcontroller activity. The total for the key exchange also takes into account consumption attributed to the radio transceiver.

In terms of network scalability, default values configure ACLs to hold a maximum of four concurrent key associations. Each increase to the maximum ACL size by one increases the table's memory footprint by 84 bytes, as illustrated in Fig. 4. With the configuration used for our experiments, we could build working firmware with a table size of up to 36 entries before we started getting linker errors.

This does not mean that the network cannot support more than 36 nodes, but that each sensor can support only up to 36 different secret keys at any time. Bearing in mind that keys are only generated between single-hop neighbors, results demonstrate that it is possible to build very dense networks (each node has 30 or more neighbors) without problems.

Energy Consumption and Key Lifetime

In this experiment we build a network of ten nodes, where one of them acts as a simple UDP sink node (server) and the rest act as clients. Four of the client nodes are out of the server's transmission range and thus the communication between them and the server is conducted through intermediate routers.

We perform multiple simulation runs, starting with a key lifetime value of 1000 seconds and for each consecutive run the value increases by 500 seconds. Simulations run for a period of two hours so that the keys expire multiple times and many key negotiations take place.

Fig. 5 presents the energy consumption of each network device, for a deployment without key exchange support and for key lifetime values of 1000 and 2500 seconds. The bars in the graph show total energy consumption, with bar portions illustrating consumption attributed to micro-processor activity, RF listening/reception and RF transmission.

Both the microcontroller's and the overall energy consumption of the server device (node ID: 0) is very high in contrast to the estimated energy consumption of the other devices. This happens because the server node has more connections and is required to establish multiple secret keys. Transmission at the server consumes the smallest amount of energy in contrast to the other nodes and reception is the highest. This is due to the functionalities the node implements, as the server transmits only its public key during the key exchange process, while the other nodes transmit their keys as well as application layer data.

Nodes acting as internal routers (node IDs 6-9) consume a large amount of energy in relation to the remaining nodes. The energy consumed by its microprocessor was spent not only to establish a secret key with the server, but also with the client nodes it serves. Similarly, the energy consumed by transmission is due to sending its own application layer messages as well as routing application layer messages towards the server. Results presented in Fig. 6 show that energy consumed by node microprocessors decreases as key lifetime increases. This happens because the keys are valid for a longer time frame and thus, fewer key negotiations are needed. The energy consumption of the server's receiver is fluctuating but remains high, because while the number of the key exchanges decreases, the number of received messages increases and thus the receiver remains busy.

The energy spent by router MCU is lower than the server's MCU energy consumption and higher than the client's average MCU consumption, as it is related to the number of the key exchanges it performs. However, as key lifetime increases, MCU energy consumption decreases.

It is observed that the average energy consumption of the micro-processor of the clients decreases as key lifetime increases. The same phenomenon applies to the energy consumed during transmission. However, consumption due to reception increases at the key lifetime of 1500 seconds, for the specific network setup.

Key Lifetime and Packet Loss

Outgoing packets are dropped at layer 2 when a secret key does not exist in the ACL table and in the case that the key exchange process is in progress. By dropping the outgoing packets the overall performance of the network is affected. However, the existence of the secret key is determined by the lifetime value, which defines whether an entry in the ACL table is valid or not.

To assess how the lifetime affects the network performance we repeat the previous simulations and measure packet loss, with results for various key lifetime values illustrated in Fig. 7. When key lifetime is set at 500 seconds the packets lost due to the lack of the key are more than 22 percent of the outgoing packets. This happens because key lifetime is short and nodes need to re-negotiate keys relatively frequently. The packet-loss ratio decreases significantly as the key lifetime increases. When the lifetime is set to 1000 and 1500 the packet-loss of the networks is 13% and 12% respectively. Eventually, when the lifetime is set to 2000 and 2500 seconds the packet-loss gets lower than 10% and 5% respectively.

Conclusions and Further Work

We developed a software implementation of the ECDH key exchange algorithm in order to assess its applicability and viability for 6LoWPANs and to examine its impact on network performance. Our method performs key exchange between two parties, but it also handles the ACL table and manages the established secret keys. Our implementation requires approximately 7.7 KBytes of code memory when built with the MSP430 GCC toolchain and used with Tmote Sky devices. This indicates that the implementation is somewhat too large for legacy sensor devices. However, contemporary devices incorporate considerably larger flash storage (e.g. 512KB) and 32-bit MCUs, allowing a significantly extended memory space. This alleviates address space restrictions posed by the original MSP430 and subsequent MSP430X architectures. Average energy consumption attributed to microcontroller activity for the computation of the public and the secret key (elliptic curve 128-bit scalar multiplication) is less than 48 mJ, and about 96 mJ for the entire key exchange negotiation. Total energy consumption is estimated to be approximately 115 mJ, with the increase being primarily attributed to the radio transceiver in listening and frame reception modes.

By simulating a larger network, we investigated the impact of the key lifetime to the overall energy consumption, network performance and scalability. We observe that packet loss decreases as key lifetime increases. This is due to two factors: i) In our current implementation, lack of a key with a neighbor results in an outgoing packet getting dropped and ii) Key negotiation itself is timeconsuming, occasionally leading to further losses. Packet delivery ratio can be improved by pro-actively triggering the establishment of a new key between two neighbors before the existing key times out.

Our scalability investigation reveals that each network node is able to keep up to 36 distinct keys in its ACL table. The approach scales well even in very dense networks; this number is sufficiently large if we keep in mind that each node only needs to establish keys with its single-hop neighbors.

The current solution is unauthenticated and is thus vulnerable to man-in-themiddle attacks, similar to the original Diffie Hellman key exchange. To address this, a method to authenticate the two parties before key negotiation would be required, with the Elliptic Curve DSA (ECDSA) algorithm posing as an attractive candidate. This is left as future work.

In terms of the time required to negotiate a shared secret, the algorithm can be further optimised. As part of our future work, we will adjust the ECDH daemon to generate Public-Private key pairs pro-actively, during node idle periods, instead of on-demand when a new key request is received. As a result, the only computationally intensive operation that will need to be conducted during key negotiation will be the calculation of the shared secret, which can take place in parallel at the two participating parties. We estimate that this will reduce the total negotiation time by approximately 60%.

In the future, ECC hardware acceleration can be employed to make the approach more viable. Hardware acceleration can have a host of positive effects: i) It can decrease code footprint, since it would mean that the implementation of elliptic curve calculations would no longer need to be included in firmware, ii) Key negotiation will be considerably faster, since ECC calculations will not need to be performed by software, iii) Assuming energy-efficient acceleration hardware, total energy consumption for the negotiation will be lower.

On contemporary sensor devices, encryption of link-layer frames is conducted by AES co-processors and is generally considered to be fast and energy-efficient. However, it is impossible to simulate hardware acceleration within the Cooja simulator. Providing a software AES implementation would have had an obfuscating effect on all metrics under investigation and since this work focused on key negotiation, we deliberately removed layer two encryption functionality in its entirety. As part of our future plans, we will evaluate the method in a real testbed with layer two encryption enabled and performed by hardware. This will allow us to draw conclusions on the viability of the complete solution.

Fig. 1 .

 1 Fig. 1. Flowchart for Secret Key Search, Frame Creation and Transmission

Fig. 2 .

 2 Fig. 2. State Transition Diagram for the Process of Key Exchange

Fig. 3 .

 3 Fig. 3. Flowchart of the Key Exchange Process

Fig. 4 .

 4 Fig. 4. Scalability with Network Density

Fig. 5 .

 5 Fig. 5. Average Energy Consumption without ECHD and with ECDH for Key Lifetime Values of 1000 and 2500 Seconds.

Fig. 6 .

 6 Fig. 6. Energy Consumption vs Key Lifetime.: Server ID:0 (left), Router ID:6 (middle); Clients (right).

Fig. 7 .

 7 Fig. 7. Packet Loss vs Key Lifetime

Table 1 .

 1 Simulation Configuration

	Parameter	Value
	Motes	Tmote Sky
	TX Range	50m
	MAC Layer	IEEE 802.15.4
	Radio Access	CSMA
	Duty Cycling	ContikiMAC
	Max Neighbors	4
	ACL Size	4
	ACL Entry Lifetime	1000, 1500, ..., 2500 secs
	Key Exchange Lifetime 50 seconds

Table 2 .

 2 Memory and Code Footprints in Bytes

	Code Module ROM	RAM data bss	Overall
	nn	3372	0	0	3372
	ecc	2494	0	676	3170
	ecdh	1477 10 392	1879
	secp128r1	402	0	0	402
	Total	7745 10 1068 8823

Table 3 .

 3 Average Time and Energy Consumption of the ECDH Key Exchange Process

		(a) Average Time Consumption (seconds)
		Public key	Secret key	Key Exchange Process
	Alice	8.560	8.547			25.586
	Bob	8.457	8.416			16.873
		(b) Average Energy Consumption (mJ)
		Public key Secret Key	Key Exchange Process MCU MCU + TX + RX
	Alice	47.176	47.226	97.021	113.224
	Bob	47.165	47.171	94.353	100.758

http://www.contiki-os.org

http://www.contiki-os.org/start.html#start-cooja


Max Günther

Bernd Borchert

Online Banking with NFC-enabled Bank Card and NFC-enabled Smartphone

Keywords: Online Banking, NFC, Smartphone, Smartcard, Signing

Banks want to use their genuine strong credential for online banking transaction authorization -the debit card. Customers nowadays are usually equipped with a Smartphone and prefer to not carry a card reader in addition. Methods where developed that use the Smartphone to authorize online banking transactions. These methods are vulnerable to Smartphone malware. We present NFC-TAN as a Smartphone method that combines the two requirements: Strong credential debit card and no additional device. We discuss to what extend this solution decreases vulnerability. Moreover, we consider usability, cost, and integration aspects of NFC-TAN.

Introduction

Modern online banking methods are secured against content-manipulation attacks with transaction-signing solutions: a separate device computes a signature depending on the details of a transaction. The necessary characteristics of a secure signature creation device have been worked out and explained [START_REF] Laurie | Choose the red pill and the blue pill: a position paper[END_REF][START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF] and corresponding online banking systems have been implemented (see Sect. 2.2) which can be considered secure against content-manipulation attacks.

However, academic approval of security is not the only success factor for online banking methods [START_REF] Shah | A survey of critical success factors in e-Banking: an organisational perspective[END_REF][START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF]. Other important factors are usability, system integration complexity, trust, bank-internal policies or business strategies, external regulations, and -maybe most importantly -costs and benefits. That is why there are many systems with different security, usability, and cost trade-offs in use today.

In this paper, we present NFC-TAN as a method that uses the genuine bankowned credential debit card (also known as bank card) to authorize PC-based online banking transactions in conjunction with a Smartphone -and nothing else. NFC-TAN works the following way [START_REF] Borchert | Sichere Verschlüsselung für Online Accounts durch ein Gerät mit Kamera, Display und Nahfunk als Mittler zwischen Rechner und Geheimnis[END_REF]: the Smartphone reads the transaction via 2D code from the PC, shows the transaction data for confirmation on its display, contacts the debit card via NFC and receives a confirmation code from the card; the customer finally transfers this code to the PC (see Fig. 1 and Fig. 2).

We think this approach is well-founded given two assumptions: Banks want to have control over the client side credential and customers do not want to carry any additional devices for authorization purposes. Debit cards offer an array of advantages: They are convenient, well known, copy proof, and already integrated into a banks credential management system.

The enabling technology for this approach is NFC (Near Field Communication): NFC-Smartphones are available and debit cards will be soon NFC-enabled. The NFC-TAN method offers a trade-off between security, usability and cost that was not possible before. This paper contributes an analysis of the security situation and a discussion of the other success factors usability and costs.

State of the Art and Related Work

Apart from credential stealing attacks, the customers' insecure Internet clients have been identified as the main vulnerability of online banking systems. Sophisticated attacks such as man-in-the-browser attacks [START_REF] Dossogne | Online banking and man in the browser attacks, survey of the belgian situation[END_REF][START_REF] Utakrit | Review of Browser Extensions, a Man-in-the-Browser Phishing Techniques Targeting Bank Customers[END_REF][START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF] were developed and already anticipated for example in [START_REF] Hiltgen | Secure Internet banking authentication. Security Privacy[END_REF]. These content-manipulation attacks can be only defeated if an online banking transaction is authorized by a signature depending on the transaction data and computed by a separate device that also displays the transaction data. If a nonce is used as additional input, also replay and pre-play attacks can be ruled out [START_REF] Bond | Chip and Skim: cloning EMV cards with the pre-play attack[END_REF][START_REF] Syverson | A Taxonomy of Replay Attacks[END_REF]. A signature in the online banking context may be symmetric or asymmetric and is termed TAN (transactionauthorization-number) or, to underline their dynamic and transaction dependent nature, dynamic-TAN or TAC (transaction-authorization-code [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF]). In this paper, we assume traditional username/password authentication at login time as this is used in most online banking systems at least in central Europe -in fact, strong login authentication seems rather unnecessary given transaction-signing solutions.

Basic Steps of Transaction Signing Solutions

Most modern online banking solutions use two devices in tandem: the PCbrowser for convenient input of transaction details and a separated device which displays those details and computes a signature for it. This approach requires two communication paths: the transaction details must be somehow transferred to the signature creation device and the computed signature must be somehow transferred to the PC (or server). The basic steps in most systems therefore are:

1. Enter transaction on the PC-browser (and send it to the server). 2. Transfer transaction details to the separated device. 3. Check (and confirm) the transaction on the display of the separated device, which computes a signature for the transaction. 4. Transfer the signature to the server (possibly via PC-browser).

Secure Signature Creation Device Solutions

In order to be considered immune against content-manipulation attacks, a signature creation device must fulfill some basic requirements. Various secure devices and corresponding online banking solutions have been proposed and implemented. From our understanding the basic properties of such devices are:

• A display that is guaranteed to show the transaction that will be signed.

• A crypto-module that is guaranteed to sign the displayed transaction.

• A signature can leave the device only if the user decides so.

• Secure storage of the credential (tamper-proof and challenge-response).

One approach to enforce the first three properties is to allow only very limited IO-capabilities (number pad + LCD display) that render malware infection virtually impossible. Especially to allow for more sophisticated interaction with the customers PC, the operating system of the signature creation device must be built securely from ground up and a button to trigger the signature computation may be necessary (if the device also has an out-channel for the signature other than the display). Laurie and Singer define a larger set of requirements to ensure the abovementioned basic properties and to add additional value (e.g. non-repudiation, updateable) [START_REF] Laurie | Choose the red pill and the blue pill: a position paper[END_REF]. The requirement to securely store a customers credential is mostly considered to be sufficiently satisfied by dedicated hardware like smartcards -laboratory-demonstrated attacks on such hardware are too expensive and therefore considered to be irrelevant for online banking systems [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF]. Likewise, we consider vulnerabilities arising from implementation deficits like those reported in [START_REF] Blom | Designed to Fail: A USB-Connected Reader for Online Banking[END_REF][START_REF] Drimer | Optimised to Fail: Card Readers for Online Banking[END_REF] to be out of the scope of this paper.

We briefly describe six characteristic external-device solutions in use today which all fulfill the abovementioned requirements for a secure signature creation device, further discussions of such and other solutions can be found in [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF][START_REF] Hisamatsu | Online banking and modern approaches toward its enhanced security[END_REF][START_REF] Singh Brar | Vulnerabilities in e-banking: A study of various security aspects in e-banking[END_REF]. In all solutions, the transaction details are entered on the PC-browser and double-checked on a separate device that also computes a signature but they greatly vary in terms of usability resp. required customer interaction. We distinguish the solutions in terms of communication/user interaction and the used crypto-module: ChipTAN [10] An offline smartcard reader (aka TAN-Generator) with photodiodes and display. This solution is of special interest for this paper, because our implementation is based on the same specifications, see Section 3.3. The so called TAN-Generator has a rudimentary optical channel consisting of five photodiodes that serially read the transaction data from a flickering code shown on the PC-display. Once the transaction is transmitted, the TAN-Generator sends it to the plugged in debit card which in turn computes and returns a TAN as a function of the transaction and a secret. The TAN is then shown on the TAN-Generators display. Manual Smartcard Reader [10] Manual variant of chipTAN without photodiodes. Communication with browser: number pad / display. Credential: secret stored on debit card. Camera Token [START_REF]CrontoSign Device[END_REF] An offline token with camera and display. Communication with browser: 2D code and camera / display. Credential: stored on device. Offline Token [START_REF] Inc | [END_REF] An offline token with a number pad and a display. Communication with browser: number pad and display. Credential: secret stored on the device. ZTIC [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF] A smartcard reader with USB connection and display. Communication with server via special protocol. Credential secret stored on smartcard. USB-Token [START_REF] One | Seal One USB[END_REF] Token with USB connection and display. Communication with server via special protocol. Credential stored on device.

Smartphone-Only Solutions

Solutions were proposed and implemented that use Smartphones instead of secure signature creation devices. For a customer the main advantage of those solutions is convenience: He does not have to carry an additional device but can instead use his Smartphone as a second display in order to check the transaction details before confirming them. The Smartphone solutions also provide communication channels for the transfer of transaction data to the Smartphone and for the transfer of the signature to the PC or server.

Photo-TAN. This class of solutions uses 2D codes to conveniently transfer the transaction data to the Smartphone via camera. A Smartphone app then displays the transaction data and computes a signature using a key stored on the Smartphone. The signature is then either sent to the server via mobile Internet or entered manually on the PC browser by the user. Photo-TAN was suggested by several researchers [START_REF] Borchert | Vorrichtung und Verfahren zur abhör-und manipulationssicheren Verschlüsselung für Online-Accounts[END_REF][START_REF] Dodson | Secure, consumer-friendly web authentication and payments with a phone[END_REF]17,[START_REF] Starnberger | QR-TAN: Secure Mobile Transaction Authentication[END_REF] and was recently implemented at some banks [1, [START_REF] Commerzbank | photoTAN[END_REF][START_REF]Cronto Limited: CrontoSign Mobile App[END_REF]. Some of these implementations work in a reversed fashion: The server encrypts the transaction and a TAN and the Smartphone decrypts the message and displays both components. Given the rise of mobile malware, Photo-TAN has severe vulnerabilities because none of the basic requirements for secure signature creation devices introduced above is fulfilled. Smartphone malware is possibly able to steal the customers signature key and send it to any recipient. Moreover it may be able to manipulate the display and the communication with the cryptomodule and send signatures to any recipient, see Sect. 4.1.

mobileTAN. Another well-known solution is mTAN. The customer enters the transaction details in the PC browser and sends them to the server. The server sends the transaction and a TAN to the customers mobile phone via text/SMS. In order to confirm the transaction, the customer enters the TAN in the PC browser (or cancels the operation if the transaction details have been manipulated). Various attack vectors against mTAN have been exploited [START_REF]The H Security: Millions stolen with mTAN fraud[END_REF], see Sect. 4.1.

Trusted-Smartphone plus Smartcard

Smartphone based solutions that assume the existence of a special execution mode sufficiently shielded against mobile malware can of course meet the abovementioned requirements for a secure signature creation device. Alpár et al. [START_REF] Alpár | Using NFC phones for proving credentials[END_REF] present one such solution using an NFC smartcard as an external crypto module and envision a user triggered trusted mode that enables the user to verify the transaction details on a then-trustworthy Smartphone display; Ortiz-Yepes [START_REF] Ortiz-Yepes | Enhancing Authentication in eBanking with NFC-Enabled Mobile Phones[END_REF] proposed a similar approach with a NFC smartcard as external crypto module. In addition, both works suggested a protocol based on the industry standard EMV-CAP (Chip Authentication Program) that avoids some of the flaws (e.g. not including the transaction data as signature challenge) found by Drimer et al. in other implementations [START_REF] Drimer | Optimised to Fail: Card Readers for Online Banking[END_REF]. The results are similar to the HHD protocol which was developed without those flaws from the outset by the German banking industry and that is used by our solution, see Sect. 3.3.

The main difference to our work is the assumption about having a Smartphone with a trusted mode. This distinction greatly influences the threat model and consequently mobile malware attacks are not covered in [START_REF] Alpár | Using NFC phones for proving credentials[END_REF] while these are a major part of our security analysis. Another difference is that we focus on twochannel PC-based online banking, while Alpár et al. discuss the natural scenario given a trusted Smartphone: single-channel mobile banking. Although trusted execution technologies for Smartphones are being developed, to our knowledge currently no commercially available device supports the full functionality.

NFC-TAN Method

Motivation

The NFC-TAN method presented below allows for online banking transaction authorization with the customers debit card as credential and his Smartphone as communication device [START_REF] Borchert | Sichere Verschlüsselung für Online Accounts durch ein Gerät mit Kamera, Display und Nahfunk als Mittler zwischen Rechner und Geheimnis[END_REF][START_REF] Günther | Sicheres Online Banking via Smartphone mit Nahfunk (NFC). Mas[END_REF][START_REF] Sattler | Einbinden der neuen NFC-Debitkarte in das Fotohandy[END_REF]. We belief this approach is justified given two assumptions:

• Banks prefer the debit card over other client side credentials. The credential debit card is already integrated into a banks credential management system: reliable processes for development, deployment and revocation are in use in any bank. A further benefit is the already implemented industry standard EMV that can be used for transaction authorization, see Sect. 3.3. • Customers do not want an additional device. An additional device is always a burden -one thing more that costs money and can get stolen, lost, or broke. In contrast, customers have their Smartphone and debit card with them anyway. Apart from these physical aspects, the credential debit card is well-known and convenient because the bank is responsible for initialization, deployment and replacement.

Description

The steps in the NFC-TAN method are quite simple and familiar to a customer because they resemble the four steps of the basic procedure described in Sect. 2.1:

1. Log in on the PC browser, enter transaction and submit it unconfirmed to the bank server. Background interaction. Under the hood, the following interaction and computation is done:

• After receiving the transaction, the bank server generates a 2D code containing the transaction details and a nonce. This 2D code is included in the server response.

• The Smartphone app builds a challenge from the transaction details and the nonce and sends it to the debit card. The debit card calculates the response as a function of the challenge and a secret key and returns it to the Smartphone app. The Smartphone app selects the TAN from this response. • The server can compute the correct TAN since it knows the transaction details, nonce, and secret key and therefore is able to check the TAN received.

Process Requirement. We require that the server has only one open session and only one open transaction at a time for one account. Our security discussion explains why this rather easy-to-implement requirement is important.

Familiarity. For many customers the NFC-TAN method may be familiar because it is similar to the abovementioned chipTAN method, the differences are: a 2D code is shown instead of a flickering code, the device is a Smartphone not a special purpose device, and debit card and device communicate contactless. NFC-TAN can be seen an extension of Photo-TAN for which the credential is stored and used on the debit card instead of the Smartphone.

Performance. Modern Smartphones are able to scan 2D-code within a second and smartcards are able to compute the response within less than a second.

Debit Card, EMV and HHD

Debit cards, or more general bank cards, are bank issued smartcards that host an array of different applications. NFC-TAN utilizes the debit cards ability to compute a signature as a function of a given challenge and a secret stored on the card. The inter-operation of terminal and card for this functionality is specified by EMV [START_REF] Emvco | EMV Integrated Circuit Card Specifications for Payment Systems[END_REF], a generic industry standard based on ISO7816 (contact) resp. ISO14443 (contactless). On the basis of EMV, card issuers developed standards for applications like ATM, POS, and online banking -with MasterCards CAP being a prominent example. The German banking industry committee Central Credit Committee, developed the standard HHD (hand held device) [START_REF] Kreditausschuss | Schnittstellenspezifikation für die ZKA-Chipkarte -HandHeldDevice[END_REF] which is used for online banking transactions. As the EMV protocol has no notion of transaction details like beneficiary's account number and amount, HHD specifies how reader devices aggregate those details into a challenge for the smartcard. The abovementioned chipTAN solution is one implementation of HHD, where the transaction is transmitted to the TAN-Generator, which aggregates the transaction and hands it over to the plugged in debit card. We based our implementation of NFC-TAN also on the HHD specification. Consequently, the Smartphone app of NFC-TAN contains a software implementation of the TAN-Generator. NFC-TAN is therefore currently compatible with the chipTAN solution but is adaptable to many solutions using EMV based or other specifications since the only strong requirement towards the smartcard is the ability to compute a response for a challenge using a stored secret.

Attacks against online banking services can be classified into three main categories: software attacks, physical attacks, and social attacks [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF]. Software attacks are the most common and the most threatening attack vectors, because they can be launched against a large number of customers with comparatively small effort and are harder to trace back than social or physical attacks [START_REF] Weigold | Secure confirmation of sensitive transaction data in modern Internet banking services[END_REF].

Software Attacks

Credential-Stealing and Credential-Abusing Attacks. The credentials of the NFC-TAN method are: password for login authentication and the signature key for transaction authorization. The password could be stolen by key loggers, phishers or social engineers. In addition, mobile malware can steal the password on the Smartphone from balance-checking bank apps which are usually protected by the same password. With NFC-TAN, the signature key is stored on the debit card and therefore out of reach of both malware and tampering.

However, malware on the Smartphone may not have to steal the signature key at all: it may be enough to be able to send a challenge to the debit card and obtain a signature. We describe how this attack is prevented in the NFC-TAN method by two countermeasures the server can implement, assuming state of the art server side session handling: (i) Only one open login-session for one customer is allowed at a given time, (ii) the server-challenge includes a nonce. Because the customer only brings the card to the Smartphone in order to confirm a transaction (and therefore has an open session) an attacker cannot initiate a transaction on its own (he would need to have an open session). The nonce prevents pre-play attacks, because a challenge obtained earlier is invalidated when the associated session is closed (at the latest), and the customer cannot open a session if the attackers is still open.

In a variant of this attack -with a collaborating malware on the PC that hijacked the customers session -Smartphone malware could try to forward an additional, malicious challenge to the debit card while the user is holding his card close to the Smartphone. This attack is prevented by allowing only one transaction at a given time and introducing a pause of some seconds between transactions.

We can conclude that the use of the debit card as a credential protects the NFC-TAN method against credential-stealing attacks. Credential-abusing attacks by Smartphone malware alone are much harder to conduct because the debit card is not permanently connected to the Smartphone. We assume a responsible and attentive customer and the server side countermeasures described above, namely (1) allowing only one session per user, and ( 2) one open transaction per session at a given time, (3) using a nonce, and (4) enforcing a delay of a few seconds between the completion of one transaction and the start of another one.

Credential-Stealing and Credential-Abusing Attacks are more Dangerous without Debit Card. Photo-TAN is an example of a method in which both credentials password and signature key can be stolen by malware, actually by malware on the Smartphone alone. The signature key is stored on the Smartphone and any attempt to secure it (e.g. key encryption via a pin or another key) is ultimately vain with respect to powerful malware, because malware could just imitate the steps executed preceding the signing algorithm, and finally will find the key. Even a pin will not prevent this because the pin is first tapped and then used in the imitating process. Malware doing this has to be sophisticated and it is not clear what the success expectation of such an attack is in practice. Nevertheless, if such an attack is successful the consequences are fatal: Malware could send the credentials to a remote attacker who can execute any banking transaction at any time! One way to store a key copy-proof on the Smartphone is a Secure Element that never exposes the key but only has a challenge-response interface. For example, Photo-TAN could be extended with such a Secure Element provided by the bank and integrated physically into the Smartphone [START_REF] Starnberger | QR-TAN: Secure Mobile Transaction Authentication[END_REF]. Malware then cannot steal the signature key but abuse it by communicating with the Secure Element and conduct an attack in the following way: First the password is tapped when the customer enters it on the Smartphone to check his account balance. Afterwards malware can open an online banking session at any time and can abuse the Secure Element to compute a signature for an arbitrary transaction without knowing the key. Restricting access to the SE for all but some signed apps may hinder this attack considerably.

This example demonstrates that using a Secure Element with permanent contact to the Smartphone can lead to vulnerabilities not present in the proposed NFC-TAN solution. It also shows that the variant of the NFC-TAN method with an NFC chip stuck on or plugged into the Smartphone is a severe degradation in terms of security though its usability is desirable. Another security issue is the distribution of the credential to the users Smartphone. A practical disadvantage for a bank is the administration effort of yet another credential.

The mobileTAN solution uses the phone number as credential. Regarding Smartphone malware that approach suffers from the fact that text/SMS messages are not considered deserving special protection on Smartphones and are generally accessible by apps, once the user granted a permission to do so -quite a common permission to ask for by all sorts of apps offered. One attack that exploits this situation is described in [START_REF]The H Security: Millions stolen with mTAN fraud[END_REF]. Another possible attack is executed by Smartphone malware alone: after stealing the account password mobile malware logs into the customers bank account and initiates a malicious transaction, intercepts the text message on the mobile phone, picks the tan and confirms the transaction. This attack can be conducted anytime the mobile is online and completely without notice to the user as no user interaction is required.

Content-Manipulation Attacks. A man-in-the-browser can manipulate the communication between bank server and PC-browser showing the transaction the customer entered, but communicating a forged one -a second display suffi-ciently separated from the PC defeats this attack. If a Smartphone with Internet access is used as second display, a content-manipulation attack can only be conducted by collaborating malware on PC and Smartphone, because both displays have to be manipulated: PC malware cannot manipulate the transaction because the Smartphone will display it again. Mobile malware cannot manipulate the transaction because the correct transaction was displayed on the PC and is already known to the server. Only collaborating malware on PC and Smartphone can perform a distributed men-in-the-middle attack by manipulating both displays. This remains a vulnerability of the NFC-TAN solution and is another example of the fact that two insecure systems do not result in a secure system.

Both malware instances need to know the original transaction (to be able to display it) and the forged transaction (in order to send it to the server resp. the debit card). They may communicate the transactions via 2D code, Wi-Fi, or an Internet server. The attack preparation includes finding and infiltrating both devices of one customer with malware. The actual independence of PC and Smartphone therefore is an important measure for the estimation about how complicated and how probable such attacks are. For example, sharing a Wi-Fi network or establishing a cable connection to synchronize calendars may increase the likelihood of a double infection.

Double infection is only a necessary prerequisite for an attack on NFC-TAN the attack itself still has to be conducted as a real-time manipulation attack. The difficulty of the attack step against the Smartphone app is probably comparable to the key theft from a Photo-TAN Smartphone app. The coordination of two distributed malware instances on PC and Smartphone alone is neither a real obstacle to attackers. Nevertheless, the attack has to involve the customers debit card and therefore the customer's interaction. Firstly, this greatly reduces the opportunities of an attack from 'nearly always' to about 'once every few days'. Secondly, the attack has to be executed in the moment the user wants to confirm a transaction, that is, within a few seconds. Therefore this attack is more difficult than the double infection attack on mobileTAN reported in [START_REF]The H Security: Millions stolen with mTAN fraud[END_REF].

Physical Attacks.

Physical attacks are often considered to be less important in the online banking context because they cannot be launched against a large number of customers. In general we agree with that estimation, therefore we only discuss one aspect particularly interesting for NFC-TAN: Wireless Attack. Enabling access to the TAN computation functionality of the debit card via NFC introduces new vulnerabilities and customers' concern because an attacker could contact the debit card unnoticed by the owner. However, the attacker still would have to know the account number and account password to complete his attack. Depending on the implementation neither the account number nor the card number can be read via NFC. Even if an attacker can associate a card with an account number and has stolen the password, a real-time attack is necessary because the server-challenge includes a nonce that prevents replay and pre-play attacks: the attacker would have to have simultaneously: an open bank session, a valid challenge and a NFC-connection within a range of 25cm [START_REF] Kirschenbaum | How to Build a Low-Cost, Extended-Range RFID Skimmer[END_REF]. Summarizing, the wireless attack is a negligible threat to NFC-TAN.

Social Attacks

For NFC-TAN customers, one reasonable briefing is important: "Only introduce your debit card to the Smartphone if you want to confirm an online banking transaction you initiated!" Then the abovementioned credential-abusing attack can be defeated because the customers open online banking session on the PC prevents Smartphone malware from opening a parallel covert one. The NFC-TAN user has a chance to prevent such an attack without an in-depth notion of the underlying security.

The user could still be tricked into signing a bogus transaction (e.g. for "service test reasons") with the NFC-TAN solution like with almost all other solutions including secure signature creation devices. This kind of attacks is easily prevented by reasonable instructions and customers attentiveness but very hard to prevent without.

Protocol / Cryptography

Since our implementation does not introduce a new protocol but reuses the specification for transaction authorization with debit cards HHD, we did not perform a security analysis of the protocol or the involved algorithms. The Smartphone does neither store a credential nor perform critical computation exactly like the TAN-generator in the HHD implementation. Since the secret on the debit card is symmetric our implementation of NFC-TAN is also symmetric. A public key implementation of NFC-TAN would be possible with suitable debit cards.

Usability

One obvious usability disadvantage as compared to other Smartphone solutions is the additional step of holding the debit card close to the Smartphone. This is balanced by the following advantages.

No Additional Device. This is especially important in a mobile scenario (e.g. in an Internet cafe) because the user does not want to carry an additional device he can lose or forget.

Convenient Communication and Display. The transaction is transferred from the PC to the Smartphone via a 2D code resp. a 2D code scanner on the Smartphone. This is usually completed in less than a second and familiar to users, as 2D codes are quite widespread. The user checks the transaction on the Smartphone display where it is possible to show a transaction completely and comfortably. In fact, the customer may check the transaction only on the Smartphone, because a manipulation by malware on the PC alone would not be a threat.

Offline Availability. The NFC-TAN method does not require an active mobile Inter-net connection on the Smartphone and therefore can be used abroad or in areas with bad network connection. This is a usability advantage compared to other solutions like mobileTAN.

Exchangeable Smartphone. As the Smartphone is a mere communication device, it is exchangeable, for example by a newly bought one or a friends one. Likewise, the credential can easily be delegated since it is stored on the debit card -this may be of benefit in a company account scenario. However, customers may prefer if Smartphone and debit card are paired, e.g. because they may consider this as an additional prevention of the abovementioned wireless relay attack.

Increasing Penetration of NFC-enabled Smartphones. In 2012 over 26% of all Smartphones sold in Europe were NFC-enabled [START_REF] Gfk | Smartphones Bring Fresh Boost[END_REF], global numbers should be similar. It is to be expected that a significant part of the customers will have NFC-Smartphones in the near future.

Complexity: Implementation, Integration and Administration

Minimal Credential Administration Changes on the Server. Banks already maintain debit cards as credentials. The NFC-TAN solution can be integrated into this system without changes to server-side credential management and distribution. Especially, no further credential is introduced and has to be administrated in parallel on the server side. If a bank already uses chipTAN/HHD for online banking, our NFC-TAN implementation can be integrated with minimal server-side efforts: only the flicker-code has to be replaced by a 2D code. This is only a user interface change, whereas business logic on the background servers remains unchanged. Consequently, both methods can be offered simultaneously to the customer.

Smartphone Application Development. In order to support NFC-TAN, a bank's Smartphone app needs to be extended by the following functionality: 2D code scanner, software implementation of the smartcard reader (TAN-Generator), and NFC communication. Although this is not trivial, there is no implementation risk because the technologies are well-known.

NFC-enabled Debit Cards. NFC-TAN needs only minimal software changes on the EMV/HHD debit card -probably only the activation of NFC is necessary (Dual Interface). In Germany, debit cards may be NFC-enabled in the medium term for this functionality -currently an electronic purse application on the debit card of some banks can be accessed via NFC.

Costs

As online banking providers are profit-oriented companies, their primary attention clearly lays on cost. Other factors are important mainly because they affect costs and revenue. This means that investments for better security measures including implementation, integration and administration have to pay off at the end of the day.

Non-Recurring expenses. The implementation of the NFC-TAN method requires development and integration costs for server and Smartphone software, see Section 6. The distribution of the NFC-enabled cards will most likely occur within the regular exchange of bank cards. Moreover, no additional software needs to be developed and installed on the debit card, see Section 6. In other words, the requirement of NFC-enabled debit cards adds no expense -neither for banks nor customers.

Recurring Expenses. The NFC-TAN method adds no direct recurring costs for a bank like device costs or per-transaction costs. Nevertheless, there will be special indirect costs like customer support and Smartphone app maintenance and indirect costs like server administration and credential management. These costs are comparable to those of other methods.

Expenses for the Customer. The customer -if he wants to use NFC-TANhas to buy an NFC-Smartphone. This may be interpreted in the way that banks move parts of their costs to their customer.

Variants and Extensions

8.1 NFC-TAN Mobile Banking (Single-Channel)

Customers may demand the following single-channel mobile banking variant of NFC-TAN: the user logs into his bank account on the Smartphone with an app or on the mobile browser and enters a transaction, and confirms it by holding the NFC debit card close to the Smartphone. This raises security issues comparable to those already discussed in Sect. 4.1. The main problem is that mobile malware alone can conduct a transaction manipulation attack. NFC-TAN mobile banking should therefore be protected by further server-side mechanisms like beneficiary white-lists, transaction limits, etc., or a trusted mode like suggested in [START_REF] Alpár | Using NFC phones for proving credentials[END_REF].

OCR instead of 2D Code

In the NFC-TAN method the transaction is transferred from the PC to the Smartphone via a 2D code. Instead, the Smartphone app could take a snapshot of the filled transaction form and recognize the transaction via OCR. This What-You-See-Is-What-You-Sign variant increases usability because the customer does not have to check the transaction on the Smartphone. Moreover, this increases security against a man-in-the-PC-browser which may speculate that user does not double-check the transaction on the Smartphone and therefore manipulate the transaction. This OCR extension of NFC-TAN may also allow a convenient and secure way to allow for collective transfers -no double-checking on the Smartphone is necessary.

Online NFC-TAN

In the NFC-TAN method, the TAN is manually transferred to the PC and then sent to the server. As a variant, the Smartphone could also send the TAN to the server via mobile Internet. This increases usability because the customer does not have to type the TAN. However, the Smartphone would have to have mobile Internet connection. Another disadvantage is increased implementation complexity on the server-side because the TAN receiving script has to be integrated.

Secure Displays

The main vulnerability of the NFC-TAN is a result from the fact that common Smartphones do not have a secure display. However, NFC-TAN could be combined with some secure display approaches. One solution would be a smartcard having a display [START_REF] Starnberger | QR-TAN: Secure Mobile Transaction Authentication[END_REF] and additional NFC-functionality. Another solution could be a Smartphone with a secure display (ARM TrustZone R / G&D MobiCore R ) and still use the debit card as a bank owned external credential in case there are reasons for not storing the credential on the Smartphone, like complexity, integration and administration overhead for a new credential.

Conclusion

We present NFC-TAN as a solution for online banking transaction authorization that uses the customers debit card as credential and his Smartphone for communication. The NFC-TAN solution is more secure than pure Smartphone solutions without sacrificing much usability. It is less secure than the secure signature creation device solutions but more convenient. Integration complexity and costs on the bank side are comparatively low since no additional credential needs to be managed. Summarizing, NFC-TAN is an online banking method with a trade-off between security, usability, and costs which was not possible until the recently beginning ubiquity of NFC-enabled devices.

Fig. 1 .

 1 Fig. 1. Basic steps of the NFC-TAN method.

2 .

 2 Scan the 2D code shown on the PC screen with the Smartphone. 3. Double-check the transaction on the Smartphone display and confirm with the debit card. 4. Transfer the TAN to the PC browser and submit it to the bank server.

Fig. 2 .

 2 Fig. 2. NFC-TAN procedure from a customer's perspective.

Acknowledgement

We would like to thank Klaus Reinhardt and Matthias Sattler for many interesting discussions and the reviewers for their valuable hints and remarks.