Simão Reis

André Zúquete
email: andre.zuquete@ua.pt

Carlos Faneca
email: carlos.faneca@ua.pt

José Vieira
email: jnvieira@ua.pt

Authenticated File Broadcast Protocol

The File Broadcast Protocol (FBP) was developed as a part of the DETIboot system. DETIboot allows a host to broadcast an operating system image through an 802.11 wireless network to an arbitrary number of receivers. Receivers can load the image and immediately boot a Linux live session. The initial version of FBP had no security mechanisms. In this paper we present an authentication protocol developed for FBP that ensures a correct file distribution from the intended source to the receivers. The performance evaluations have shown that, with the best operational configuration tested, the file download time is increased by less than 5%.

Introduction

The DETIboot system is a solution that was designed and developed to quickly install a temporary, live Linux image in an arbitrarily large number of computers [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF][START_REF] Faneca | Fast image file distribution with Fountain Codes via a Wi-Fi Ad-Hoc network, using low power processors[END_REF][START_REF] Faneca | DETIboot: A fast, wireless system to install operating systems on students laptops[END_REF]. It uses a wireless 802.11 network (WiFi), operating in ad hoc mode, and broadcast communication to send the Linux image to nearby clients. These load the image and immediately boot a Linux live session, which can disappear without leaving a trace after a power down. This system has potential applications in both academic and enterprise environments. Currently we are working on a security ecosystem for DETIboot in order to allow its use in exams using students' personal laptops and an hardened Linux image.

The DETIboot system uses a broadcast file distribution protocol (FBP). The first version of FBP had no security mechanisms, which is not advised for ensuring a correct distribution of the intended Linux image among all receivers. In this paper we propose a broadcast authentication protocol for FBP, which enables FBP receivers to make a correct download from an intended FBP server.

Our authentication protocol kept the basic behaviour of FBP. The authentication is performed with extra messages (authenticators) interleaved at unpredictable places within the original FBP frame transmission flow. These authenticators enable a set of future frames to be authenticated by the receivers. The option for sending an authenticator before its target frames was taken for preventing receivers from accumulating frames that may never be authenticated.

Authenticators use well-known technology: SHA-1 frame digests, signed with an RSA private key. For the envisioned exploitation scenarios we use highperformance RSA setups (1024 bit modulus, small public exponents) for increasing performance without compromising security. The setup of an FBP session is driven by parameters derived from the public key of the FBP server, which guaranties that receivers cannot be fooled by networks deployed by attackers.

For evaluating the performance of our proposal, we did measurements in multiple operational scenarios, considering different reception conditions, different timings for sending authenticators and the presence of an attacker. Without attacks, the overhead in the total download time for a more aggressive transmission of authenticators, the one with better results, was below 5%.

This paper is structured as follows. In Section 2 we present the FBP concepts that are fundamental to understand the options we took for adding authentication, as well as its security weaknesses. In Sections 3 and 4 we present our FBP authentication protocol and some implementation details. In Section 5 we present the performance evaluation of FBP with authentication. In Section 6 we present some related work in the area of broadcast authentication. Finally, in Section 7 we present our conclusions.

File Broadcast Protocol

In this section the File Broadcast Protocol (FBP) is described in order to clarify the scenario that needs to be protected.

FBP [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF][START_REF] Faneca | Fast image file distribution with Fountain Codes via a Wi-Fi Ad-Hoc network, using low power processors[END_REF][START_REF] Faneca | DETIboot: A fast, wireless system to install operating systems on students laptops[END_REF] uses Fountain Codes [START_REF] Byers | A digital fountain approach to asynchronous reliable multicast[END_REF][START_REF] Mackay | Fountain codes[END_REF] to broadcast a file. Fountain Codes create a sequence of codewords that can be generated from a given set of source symbols such that those symbols can be recovered from any subset of the codewords of size equal to, or only slightly larger than, the number of source symbols.

FBP starts by slicing the file to be transmitted into a set of equally-sized segments (source symbols). Pseudo-random XOR combinations of those segments are then calculated, yielding Fountain Code codewords. FBP repetitively and indefinitely broadcast codewords from a server to multiple clients. The transmitter encodes file segments into codewords and the clients decode those codewords, obtaining the original file segments.

FBP clients may enter at any time in the broadcast session, they do not need to be present at the begging of the FBP transmission. Furthermore, they are tolerant to packet losses since, in theory, it does not matter the exact set of codewords one needs to receive (all codewords are equality good to get the original symbols). After a given threshold of received codeword it should be highly probably to complete the decoding and get all the original symbols.

FBP is a network protocol (layer 3 of the OSI model), identified through the Ethernet code 0x1986 in 802.11 frames. An 802.11 codeword frame conveys the codeword itself and the indexes of all symbols used to generate it. The indexes are not transmitted directly, they are derived by receivers from parameters included in the frame: total number of symbols (K), degree of the codeword (number of symbols used in its generation), and a random seed (cf. Figure 1). The degree and the seed, together with a universal pseudo-random generator, are used to generate the index set of the symbols contained in the codeword. A codeword frame also includes a codeword index (a sequence number) for performance evaluation purposes. We used it also for defining authentication windows.

Security vulnerabilities / attacker model

FBP uses a wireless medium, through 802.11 ad-hoc networks, to broadcast codewords of a boot image from a source to many destination laptops. Thus, an attacker can try to impersonate a legitimate source in order to provide its own boot image. Alternatively, the attacker may provide only a few codewords that would act as a Trojan Horse, i.e., could change the final behavior of the boot image while keeping most of its functionality unchanged. This is not easy, but certainly not impossible.

Besides those attacks, where the attacker could attempt to control the downloaded boot image, an attacker can use Denial of Service (DoS) attacks. In this case, it can (i) repeat previously sent codewords or (ii) prevent legitimate codeword transmissions or receptions.

In the first case, which is a typical replay attack, it would increase the receivers' memory with useless codewords, but not ruin the codeword decoding process (repeated codewords can, in fact, happen). In any case, it is advised to discard repeated codewords if we are able to detect such situation.

In the second case, involving interference with a legitimate transmission and reception, there is no definitive solution, because jamming or abusive 802.11 medium occupancy is always possible. Nevertheless, we can make an attacker's task harder by forcing it to interfere continuously with the legitimate transmitter. In fact, since FBP codewords do not need to be strictly ordered and can be lost, as long as a receiver is able to get codewords, even at a lower rate, it will continuously evolve towards a complete codeword decoding. The only way to avoid this is by preventing receivers to get any codewords at all.

Another type of attack involves the name resolution used in ad hoc networks. These networks, formally referred as Independent Basic Service Sets (IBSS), can be identified by names, which are assigned to 48-bit values (BSS IDentifiers, BSSID). Usually, the binding between a network name and a BSSID is made by any node that attempts a network name resolution within the neighbors and gets no answer. Thus, it is perfectly possible to have a legitimate FBP transmitter and an attacker with the same network name bound to different BSSID values. In this case, FBP receivers should not resolve network names to BSSID values, because they may get the attacker's BSSID, thus entering its network thereafter. In such case, the attacker could impersonate the legitimate FBP transmitter, providing its own boot image, or remain silent, this way deploying a DoS black hole attack. Since the name resolution is a basic 802.11 feature, which cannot be changed or protected in any way, the obvious solution is to force the BSSID of FBP receivers to a value known to be in use by the legitimate FBP transmitter.

Finally, assuming that FBP needs some mechanism to enable receivers to check the validity of the codewords they receive, this mechanism should be designed in a way that does not allow an attacker to interfere with it with a minimum effort. Otherwise, it would be easy for an attacker to force receivers to discard all legitimate codewords. The autonomous authentication of each and every codeword could be a solution, but the overhead costs, both in terms of data transmission and CPU processing, could as well be excessive. On the other hand, the transmission of a few, critical authentication control frames, which could be used to authenticate many codewords, cannot be predictable (i.e., nobody should be able to guess their transmission slot). Otherwise, an attacker could simply jam those control frames to interfere with, an completely ruin, the entire codeword reception process.

Authentication requirements and alternatives

As referred in [START_REF] Perrig | Secure Broadcast Communication: In Wired and Wireless Networks[END_REF], the solutions to reliable, point-to-point packet communications do no scale well to broadcast environments. In point-to-point is usual that receivers request retransmission of the data in case of failure. FBP solves this issue for broadcast communication by using Fountain Codes, which do not require feedback. Furthermore, authentication in point-to-point communications can be achieved with a pure symmetrical solution, such as a Message Authentication Code (MAC). Both parties share a common secret key, and when a message with a correct MAC arrives the receiver is assured that the correct transmitter generated it. However, in a broadcast environment a MAC is not safe. Every party knows the MAC key, therefore anyone could impersonate the genuine source and assume the broadcast transmission. The obvious approach is the use of an asymmetric mechanism, such as a digital signature. These have the asymmetrical authentication property required by FBP: each source generates signatures with its private key and the receivers can verify the signatures with the public key of the intended source.

An FBP receiver needs to know something about a legitimate FBP transmitter to authenticate it, or the codewords it sends. However, an FBP receiver should process codewords immediately upon their reception, to maximize the decoding CPU cycles between the reception of consecutive frames. Consequently, it is advised to either (i) authenticate each codeword independently from the others or (ii) to transmit a multi-codeword authentication frame prior to a transmit the respective codewords.

The natural solution for the first option is to include in each codeword a signature, produced by the FBP transmitter and that could be verified by each an every receiver. However, ordinary signatures, such as the ones made with RSA, can take a relevant space in the codeword frame. For a typical codeword with nearly 1500 bytes, an RSA signature using a 1024-bit modulus would add 128 more bytes to a codeword. This means about 9% more data to transmit per codeword. Since to overall decoding time is a function of the time it takes to receive a minimum number of codewords, with this authentication strategy the overall decoding time would increase by no less than 9%. This is not dramatic, but we thought we could get a better solution, and we did.

The second option is to transmit authentication frames with authentication material for the frame itself and for checking a set of codewords following it. A simple strategy for implementing this authentication policy would be to include in a authentication frame a set of references and digests of future codewords, all signed by the FBP transmitter. With a 1500-byte frame and an 128-byte RSA signature we have room for about 60 20-byte SHA-1 digests. Without frame losses, this strategy has an overhead lower than 2% relatively to the data transmitted, because we only need to transmit an authenticator (and the correponding public key to validate it) before a batch of 60 codewords. However, with frame losses the overhead is higher, because upon the loss of an authenticator the receiver would have to discard all codewords until getting the next authenticator.

Regarding attacks, the second option is potentially weaker than the first against DoS attacks. In fact, if an attacker could predict the instant when authenticators are transmitted, then it could jam the network during such transmission and, with a minimum effort, could prevent the validation of all received codewords. However, this weakness can be mitigated by adding some randomness to the instants when authenticators are transmitted. For instance, the transmitter can insert a variable number of codewords between authenticators, ranging from 1 and up to the maximum of digests present in the previous authenticator. With this strategy, an attacker could never anticipate the transmission of an authenticator, therefore selective jamming would not be possible any more.

Authenticated File Broadcast Protocol

This section presents the authentication extension developed for the FBP protocol. In this extension we used the last solution presented in the previous section: special authentication packets, interleaved from time to time with codewords, which authenticate a fixed number of following codewords.

Design assumptions and options

Our authentication protocol was conceived for an operational environment where a new, fresh asymmetric key pair can be create and used in a time-limited file download session. For instance, it can be use to download a particular live Linux distribution in the beginning of a class, possibly taking no more then a few minutes. Or we can use a daily key pair for on-demand distribution of live Linux distributions for the computers of an organization (e.g. a demonstration distribution for all laptops being presented in shelfs of a computer store).

In both cases, we take the two following assumptions: (i) key pairs can be changed frequently, on a per-session basis, and do not need to stay stable for a long time; and (ii) the receivers can get, from a reliable source, some elements that allow them to verify if a public key is the correct one they should use. In this last case, we did not consider any automatic validation strategies, such as public key certificates or certification chains, but rather some human-driven mechanisms, such as the validation of the equality between digests.

Taking into consideration the first assumption, there is no need to use very long asymmetric keys; we chose 1024-bit RSA keys. Furthermore, we used the smallest Fermat prime (3), as the public exponent, which reduces to the minimum the computation overhead in the receivers without bringing known security vulnerabilities. We have chosen SHA-1 as the algorithm to compute the digest of each codeword. Currently it has no known vulnerabilities and the digests are not excessively long.

Key distribution and validation

Each authenticator carries the modulus of the public key of its generator, as well as a signature produced by the corresponding private key. When a receiver starts, it waits for an authenticator, checks its signature, presents a digest of the public key to the user and waits for an accept/reject decision. This decision must be taken upon checking, by some means, if the digest is the expected one. For instance, in a classroom, the teacher controlling the source machine can get the same digest and write it in the board.

For segregating communications involved in different FBP sessions, the overall key-related setup is slightly more complex:

1. The sender initiates the FBP server, this generates a fresh key pair for the transmission session. Then, it computes (and displays) a digest from its public modulus and uses part of that digest to compute (and display) the BSSID of its ad hoc network. This BSSID can or cannot be already in use, that is irrelevant for FBP. 2. The receiver initiates the FBP client with the BSSID being used by the intended server, in order to enter its ad hoc network. 3. The FBP client waits for an authenticator, which it will use to present the digest of its public modulus. If the user approves its value, the modulus is recorded for checking future authenticators. 4. The FBP client waits for a valid (properly authenticated) codeword for extracting the download operational parameters -number of symbols K and size of each symbol/codeword. Once having this, the decoding process can start (using this and the following valid codewords).

Ethernet packets have a payload of 1500 bytes. Subtracting the size of the public RSA modulus (128 bytes), the size of the corresponding signature (128 bytes), the remaining space can, at the maximum, accommodate 62 20-byte codeword digests. We decided to use only 60, leaving some space in the authenticator for some extra fields that could be necessary.

Each authenticator can authenticate 60 consecutive codewords. Considering that authenticators are equal in size to codewords (the difference is small), at least 1 61 (∼1.6%) of all transmitted bytes will be exclusively used for authentication. By increasing the transmission frequency of authenticators we increase accordingly such overhead. This can be a low price to pay when transmission losses increase, affecting the number of received authenticators. We will address this issue in Section 5.

Authenticator generation

Before sending a set of 1 ≤ N ≤ 60 previously generated codewords, the FBP server creates an authenticator to protect the next 60 RSA signature of the transmitter over this index and all the digests and the signer public key modulus (see Figure 1).

≥ N codewords (C x , • • • , C x+59 ). For each codeword C i , with i ∈ [x, x + 59], a digest d i = h(C i ) is calculated
Upon checking the validity of an authenticator, an FBP client saves all its digests to validate future codewords. For instance, if the last codeword index in the authenticator is 2000, only the 60 codewords with an index between 1941 and 2000 can be checked and possibly accepted by the client. If in the meanwhile another valid authenticator is received, this validation information is updated accordingly for authenticating the following codewords.

Figure 1 shows the complete physical mapping of an authenticator's fields. The second field, corresponding in terms of location to a codeword's field K, is always 0. Since K is never 0 in codeword frames, this field can be used by clients to distinguish codewords from authenticators. The session identifier is used to efficiently discard authenticators belonging to a different download session (sharing, by a very unlikely coincidence, the same 802.11 channel and the same BSSID value). This identifier is randomly chosen by an FBP server and adopted by a receiver upon the acceptance of an authenticator that carries the public modulus that will be used to authenticate the traffic.

Replay attacks against clients

To prevent replay attacks, authenticators with an outdated latest codeword index (lower than the one of the current authenticator being used) are discarded by clients without further validation.

The codewords' index is also checked to avoid replay attacks. The client saves the index of the last (valid) codeword and discards codewords with a previous or equal index without further validation. Note that we are working with a one-hop wireless network, where frames, in principle, do not get out of order.

Implementation details

Key generation and distribution

The FBP server was modified to generate an RSA key pair with the public exponent 3. Besides including the modulus of this key in all authenticators, the server outputs for its administrator an SHA-1 digest of the modulus and a 48-bit BSSID extracted from part of such digest. These two values need to be conveyed, by the best suited means, to all the users running the FBP client and wishing to download a file from this server. The BSSID is used by the server to initiate the ad hoc network prior to start using it.

The FBP client was modified to accept a BSSID (formerly it was using a name-BSSID translation). Then it waits for an authenticator, displays the SHA-1 digest of its public key modulus, and prompts the user if that is the key to be used. The user has the options to (i) use it, (ii) do not use it once, (iii) do not use it forever, or (iv) input the SHA-1 digest or the desired modulus. Thus, flooding attacks exploring constant or always changing modulus on each authenticator can be overcome by either (i) choosing not to use a modulus forever or (ii) providing the digest of the correct modulus, respectively.

Production of authenticators

The server was implemented as a pipeline of 3 tasks: (i) produce the codewords, (ii) build the authenticators and (iii) send both the codewords and the authenticators. Most laptops nowadays are multiprocessor so these tasks can be assigned to an equal number of threads (Producer, Signer and Sender), each on its own CPU, in order to maximize the CPU usage. These tasks manage two circular buffers that are used for queueing codewords and authenticators (see Figure 2). The Producer thread is the first to start. It produces as many codewords as possible (action 1 in Figure 2). As soon as there are enough codewords (at least 60) to fill an authenticator with their digests, the Signer thread starts. Upon having at least one authenticator, the Sender thread starts.

There are 4 synchronization points, implemented with semaphores: two between the Producer and the Signer; one between the Producer and the Sender and one between the Sender and the Producer. These are represented by the thick vertical lines in Figure 2. Preliminary tests indicated that synchronization points between any pair of buffer items would cause to much computational of overhead. So, these 4 synchronization points are done in blocks of 60 items. The Producer needs only one block; while inside it, it produces as many codewords as possible. The Signer needs two blocks, because each authenticator must always protect the next 60 codewords, and some may be in the next adjacent block. The Sender only needs one block. In total, 4 blocks of 60 items are needed.

As we can see in actions 2 and 3 in Figure 2, the Signer always saves the authenticator in the same index as the first codeword it authenticates. In actions 4 and 5 in Figure 2, the Sender at index i of a block b checks if in the authenticators' queue there is a authenticator for the same index. If there is, it sends it, and then it sends the codeword in the same position of the codewords' queue. Otherwise, it only sends the codeword in that position.

Performance Evaluation

The performance evaluation involved reaching two fundamental conclusions: (i) what is the overhead, under normal conditions (i.e., when not being attacked), of our FBP authentication and (ii) what is the preferable frequency for sending authenticators.

To reach these conclusions we have made a series of live measurements considering all possible scenarios combining the following parameters:

-A receiver near or far away from the transmitter. For the near case we experienced an average RSSI (Received Signal Strength Indicator) of -25 dBm, while for the far case we experienced an average RSSI of -75 dBm) (evaluated with Android mobile phones using the Wifi Analizer application). -A variable number C of codewords between each authenticator, uniformly distributed in the intervals [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]30] and [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]60]. The first interval leads to an higher frequency in the transmission of authenticators. -The presence of another transmitter using the same wireless network (same 802.11 channel, same BSSID) and close to the receiver.

For transmissions without authentication we obtained the following indicators: (i) decoding elapsed time (Time); (ii) the number of codewords effectively used for reaching the complete file decoding (Used); (iii) the number of codewords received by the decoder but not effectively decoded (Unused); and (iv) the number of codewords lost in the transmission, due to physical transmission problems or overruns of reception buffers (Lost). This last value is computed from the indexes of the first and last codewords (F and L, respectively) received by the decoder and the total number of codewords received by the decoder (R):

Lost = L -F + 1 -R Since R = Used + Unused, then Lost = L -F + 1 -(Used + Unused)
The (percentage of) codeword loss in the decoding process is given by

Loss = Lost R + Lost = Lost Used + Unused + Lost
For transmissions with authentication we obtained all the previous indicators plus the following: (i) the number of codewords from the correct source that failed authentication (Invalid); and (ii) the number of codewords from other sources that also failed authentication (Other). To distinguish codewords from the correct or incorrect source we used the K of each codeword and all codeword sources broadcast files with a different K. With authentication the calculation of Lost is different, being given by Lost = L -F + 1 -(Used + Unused + Invalid) and the (percentage of) codeword loss in the decoding process is calculated as

Loss = Invalid + Lost Used + Unused + Invalid + Lost
In the measurements we used the following systems and data:

Legitimate transmitter: Toshiba Portégé 830-10R, with an Intel Core i7-2620M at 2.7 GHz, 8 GiB of RAM, with an external (USB) Thomson TG123g WiFi interface (with the TxOP option [START_REF]IEEE Std 802.11e: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 8: Medium Access Control (MAC) Enhancements for Quality of Service (QoS)[END_REF] for fast transmission3 ), running a 64-bit Linux Lubuntu. It was used to transmitted a file with 104, 792, 660 bytes (∼100 MiB, 70615 symbols, each with 1484 bytes). Receiver: Asus K55VM-SX083V, with an Intel Core i5-3210M Dual Core at 2.5 GHz, 8 GiB of RAM, Atheros AR9485 WiFi interface, running a 64-bit Linux Lubuntu at runlevel 1 (single user administration mode). Attacker: Asus F3SC-AP260C, with an Intel Core 2 Duo T5450 at 1.67 GHz, 1 GiB of RAM, running a 32-bit Linux Lubuntu.

Note that the attacker can be as powerful as intended, as it can be deployed with different machines. In our case, the attacker was made intensionally less powerful than the correct FBP source.

In all transmissions we used 802.11g broadcast at the maximum speed allowed by interface drivers. For the legitimate transmitter we could set that speed to 54 Mbit/s, the 802.11g maximum. When combined with the TxOP, the nonauthenticated FBP can achieve a download performance of about 40 Mbit/s. Without such option, the maximum performance drops to about 25 Mbit/s.

Tables 1, 2 and 3 present the average and standard deviation values observed for the elements previously referred in the several scenarios considered. All values were computed after 10 experiments in the same exact circumstances.

Analysis of results

The results show a typical result of our coding policy: the number of codewords required for completing the file decoding is fairly stable in all cases. However, the time to get those codewords varies a lot depending on the scenario.

Regarding our first goal, compute the overhead introduced by the authentication in normal circumstances (when not being attacked), we see that the overhead is small. Table 4 shows the overheads due to the introduction of authentication. In terms of decoding time, the increment ranged from 3.5 to 4.8% when the frequency of authenticators is higher (C ∈ [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]30]), and 1.3 to 72.2% when such frequency is lower (C ∈ [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]60]). In terms of codeword losses, this value increased due to the discarding of invalid codewords. The increase was between 0.5 and 1780.1% when authenticators are more frequent, and between 773.9 and 2086.5% when authenticators are less frequent.

There is an apparently strange outcome, which is the fact that, despite a major increase of losses with authentication, the total decoding time does not increase on the same proportion. Notice, however, that if we have erasure rates (total losses) n and f for a nearby and far way transmissions, respectively, for reaching a threshold X of codewords in the decoder enabling it to complete the decoding we need to transmit N n and N f codewords, in each case, such that

X = N n × (1 -n ) X = N f × (1 -f ) which means that N f × (1 -f ) = N n × (1 -n ) ⇔ N f N n = 1 -n 1 -f
Now, for n = 0.0009 and an f = 0.6995 (observed with high frequency authenticators, see Table 2), we get

N f
Nn ≈ 3.325. Since there is some linear correlation between the decoding time T and the total number of transmitted codewords during the decoding (N ), we can also anticipate that

T f
Tn should yield a similar value, which it does: 74.0 21.0 = 3.442. This demonstration is also applicable to the results obtained for transmissions with less frequent authenticators.

Regarding our second goal, finding a preferable frequency for sending authenticators, the tests allow us to conclude that, except in one case, it is preferable to use a higher frequency (C ∈ [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]30]) than a lower one (C ∈ [START_REF] Cardoso | DETIboot: distribuição e arranque de sistemas Linux com redes WiFi[END_REF]60]). With an higher frequency the Time and Loss indicators, the ones that are relevant to evaluate the transmission efficiency, are usually lower than with a low frequency. The increase of Loss is partially due to the increase of the Invalid indicator, which grows when authenticators are transmitted less frequently.

The exception happens when the receiver is very close to the transmitter and there is not an attack. Besides being an hard-to-find scenario (not all receivers can be this close, specially when there are many or they are scattered along a classroom), the difference in the average decoding time is negligible (∼ 2%) for deciding for a lower frequency.

When an attacker is present and competes for the transmission media, it will succeed in reducing the FBP performance. This is evident from the comparison of the results of Tables 2 and3. However, such results show a curious behaviour: when the attacker and the victim are close to each other, an far away from the genuine source, the Other indicator drops when comparing with the scenario were all three hosts are near each other. This is probably due to transmission collisions between the genuine source and the attacker, which have difficulties in listening to each other traffic.

We have used SHA-1 both for computing the digests of codewords and the authenticators' signatures. Since SHA-1 is deprecated for digital signatures [START_REF] Barker | Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths[END_REF], we should probably use stronger digest functions, such as SHA256 or SHA512, for handling signatures. We did some experiments with SHA256 and the performance results were very similar to the ones observed with SHA-1, which means we can increase security without compromising performance.

Related Work

Regarding the authentication of Fountain Code transmissions, in [START_REF] Bohli | Security enhanced multi-hop over the air reprogramming with fountain codes[END_REF] the authors developed a solution for authenticating Fountain Code codewords used in the distribution of a new image in multi-hop wireless sensor networks. Their solution is totally different from ours: they recode the original symbols to include digests of other symbols, forming an hash chain up to a new root symbol that needs to be transmitted authenticated and without Fountain Codes. The digests can only be recovered when original (recoded) symbols are recovered, and for building the complete digest tree one needs to recover (recoded) symbols with a particular order. In the mean time, recovered symbols that could not be verified are dropped. Although using Fountain Codes, there is an initial time for the transmission, when the root symbol is transmitted.

Regarding the authentication of other broadcast transmissions, there are numerous contributions using various strategies. We will not go through all individual contributions, but rather highlight those strategies with some references.

Signature amortization methods are similar to our approach: they compute a signature relatively to a set of frames to reduce the signature generation and verification overhead. This approach can be complex to implement if one could not verify a signature upon loosing a related frame (as in [START_REF] Park | Efficient Multicast Packet Authentication Using Signature Amortization[END_REF]) or if we could not verify a signature until receiving a set of frames (as in [START_REF] Wong | Digital Signatures for Flows and Multicasts[END_REF]). We solved these problems, as we tolerate codeword losses and we can immediately verify the validity of a codeword upon its reception at the decoder, with a false negative rate that is a function of the frequency of authenticators.

Symmetric key schemes were used in some secure broadcast approaches, such as TESLA [START_REF] Perrig | Efficient authentication and signing of multicast streams over lossy channels[END_REF], but TESLA requires a synchronized start by all receivers (which we do not) and frames cannot be immediately authenticated, only after receiving a few other frames (which we do not want and we do not need to).

In [START_REF] Yavuz | An Efficient Real-Time Broadcast Authentication Scheme for Command and Control Messages[END_REF] the author developed a mechanism, called Rapid Authentication, that enables the use of precomputed data in the creation of RSA signatures. His goal was to accelerate the individual signature of Command & Control Messages for an efficient, real-time transmission. This is not a problem for us, since we do not need to sign each and every codeword, just authenticators, and this can be done in parallel with the production and transmission of codewords.

Conclusions

In this paper we have presented a solution for adding a lightweight source authentication to codewords transmitted by an FBP server. The goal was to prevent a nearby attacker to compromise codeword receptions by adding wrong codewords.

The solution we have presented uses well-known and widely accepted technologies (SHA-1 digests and RSA key pairs and signatures) to produce and check codeword authenticators. These are transmitted before the actual transmission of the codewords they authenticate, which enables receivers to validate codewords immediately upon their reception. Authenticators are transmitted at a variable and unpredictable pace, which prevents attackers to make surgical jamming strikes against them. Using a higher rate for sending authenticators we achieved very good performance result, with a maximum overhead of less then 5% in the total file decoding time. Note that this overhead already includes the public key distribution, which is performed by all authenticators.

The distribution of the public module of the RSA key pair used to authenticate an FBP session was adapted to the operational scenarios where FBP was designed to be used within DETIboot: for transmitting a file (usually a Linux live distribution image) to an arbitrarily large population of nearby receivers (e.g. in a classroom). Since these are sufficiently close to the transmission source to make eye contact, the critical information regarding the public key modulus (its digest) and the ad hoc network BSSID can be conveyed in a simple and straightforward way: by writing somewhere where it could be seen by all receivers (e.g. on the classroom board).

Fig. 1 .

 1 Fig. 1. FBP frame payloads for codewords (left) and authenticators for transmitting before codeword index x (right)

Fig. 2 .

 2 Fig. 2. Tasks, buffers and actions used to coordinate the production and transmission of codewords and authenticators

  and inserted into the authenticator. The authenticator also carries the index x + 59 of the codeword used to compute the last digest (d x+59 ), an

	codeword index	(4 bytes)	last codeword index: x + 59	(4 bytes)
	K	(4 bytes)	0	(4 bytes)
	seed	(4 bytes)	session identifier	(4 bytes)
	degree	(4 bytes)	SHA-1 digests: dx, dx+1, • • • , dx+59	(1200 bytes)
	codeword	(1484 bytes)	RSA signature & public key modulus (256 bytes)

Table 1 .

 1 Results at the end of the file decoding without authentication

		Time (s)	Used	Unused Loss (%)
	Distance Avg	σ	Avg	σ Avg	σ Avg	σ
	Near	20.8 0.9 72102.0 171.3 913.6 540.2 0.09 0.09
	Far	70.6 6.4 72238.4 137.3 151.3 111.6 3.72 0.12

Table 2 .

 2 Results at the end of the file decoding with authentication and no attackers

			Time (s)	Used	Unused		Invalid	Lost	Loss (%)
	Distance	C	Avg	σ	Avg	σ Avg	σ	Avg	σ	Avg	σ Avg	σ
	Near	[1, 30] 21.5 0.1 72141.1 212.5 493.6 328.9 [1, 60] 21.0 0.1 72212.7 236.4 591.3 343.0	25.6 161.2	5.4 53.5	42.6 437.7	28.2 0.09 0.04 87.4 0.82 0.12
	Far	[1, 30] 74.0 14.5 71989.3 132.0 228.0 310.6 8107.3 2069.3 168894.7 46626.2 69.95 6.27 [1, 60] 121.5 40.3 71943.1 156.3 147.2 270.7 30170.0 6624.8 314448.3 132831.6 81.34 4.94

Table 3 .

 3 Results at the end of the file decoding with authentication and an attacker

			Time (s)	Used	Unused		Invalid		Lost	Loss (%)	Other
	Dist.	C	Avg	σ	Avg	σ Avg	σ	Avg	σ	Avg	σ Avg	σ	Avg	σ
	Near	[1, 30] 35.5 0.4 71949.3 145.4 616.8 262.8 [1, 60] 36.0 2.1 72155.2 409.9 548.2 281.4 7144.1 1329.5 20811.5 820.2 101.5 23006.3	681.2 24.7 0.6 20436.3 23.9 4384.4 27.6 4.0 20917.0 20.5
	Far	[1, 30] 87.8 32.7 72061.8 363.9 238.3 330.3 9925.3 3728.8 209600.6 105077.0 72.3 9.3 2610.0 68.9 [1, 60] 135.8 37.2 72033.8 174.8 38.8 68.2 35275.0 5758.2 358082.8 126205.5 83.7 4.1 3265.3 75.8

Table 4 .

 4 Overheads in the decoding time and codeword losses due to authentication

	Distance C ∆ Time (%) ∆ Loss (%)
	Near	1-30 1-60	3.5 1.3	0.5 773.9
	Far	1-30 1-60	4.8 72.2	1780.1 2086.5

TxOP allows a transmitter to send batches of frames separated by the minimum possible time, a SIFS (Short Interframe Space).

Acknowledgment

This research work was supported by the projects PTDC/EEI-TEL/3006/2012 (CodeStream) and PEst-OE/EEI/UI0127/2014, both from FCT (Foundation for Science and Technology).


Christoph Pohl
email: christoph.pohl0@hm.edu

Alf Zugenmaier
email: alf.zugenmaier@hm.edu

Michael Meier
email: michael.meier@fkie.fraunhofer.de

Hans-Joachim Hof
email: hof@hm.edu

B.Hive: A Zero Configuration Forms Honeypot for Productive Web Applications

Keywords: Web application, honeypot, security, web security, network security

Honeypots are used in IT Security to detect and gather information about ongoing intrusions by presenting an interactive system as attractive target to an attacker. They log all actions of an attacker for further analysis. The longer an attacker interacts with a honeypot, the more valuable information about the attack can be collected. Thus, it should be one of the main goals of a honeypot to stay unnoticed as long as possible. Also, a honeypot should appear to be a valuable target system to motivate attackers to attacks the honeypot. This paper presents a novel honeypot concept (B.Hive) that fulfills both requirements: it protects existing web application in productive use, hence offering an attractive attack target, and it uses a novel technique to conceal the honeypot components such that it is hard to detect the honeypot even by manual inspection. B.Hive does not need configuration or changes of existing web applications, it is web framework agnostic, and it only has a slight impact on the performance of the web application it protects. The evaluation shows that B.Hive can be used to protect the majority of the 10,000 most popular web sites (based on the Alexia Global Top 10,000 list), and that the honeypot cannot be identified by humans.

Introduction

Honeypots are well known and valuable components for the protection of networks. They can be used for attack detection or for research purposes. Usually, a honeypot is a fake system without any function that runs in parallel to other productive systems. Thus, all activities detected on the honeypot can be considered attacks (or unintended use). However, a honeypot can only monitor ongoing attacks if it succeeds in tricking attackers into attacking the honeypot at first. To do so, a honeypot must be known to an attacker and it should appear like a real application or service. In order to maintain the attackers interest and to maximize the attackers interactions to gather as much information about the attack as possible, attackers should not be able to notice that the system they are attacking is a honeypot. The approach presented in this paper, B.Hive, blends into already existing and running web applications (further called target applications). As the honeypot components are completely invisible to benign users, any interaction with it is likely an attack. As an existing, productive web application is used, attacks on this system are likely.

The contribution of this paper is twofold: It presents a zero configuration Low Interaction Honeypot that can blend into any existing and running web application. Furthermore, it employs a technique that makes it substantially harder for an attacker to detect that honeypot components were integrated into a web application, even when manually inspected by humans. B.Hive does not need configuration for the integration, and the protected web application does not need to be changed. B.Hive is ideal to be integrated into active protection components like the web application firewall "All-Seeing Eye" [START_REF] Pohl | The all-seeing eye: A massive multi-sensor zero-configuration intrusion detection system for web applications[END_REF].

The paper is structured as follows: The next Section 2 gives an overview on B.Hive. Related work is described in Section 3. Design and implementation is explained in Section 4. Section 5 validates the concept and shows that performance of the prototype implementation would allow augmentation of all but the busiest web applications. Section 6 summarizes the paper and gives an outlook on future work.

Overview

The Open Web Application Project (OWASP) maintains a list of the ten most prevalent attacks on web application in [START_REF]OWASP: Top 10 2013 -OWASP[END_REF]. For four of these attacks, named A1 (Injection), A3 (Cross-Site Scripting (XSS)), A8 (Cross-Site Request Forgery (CSRF)), and A9 (Using Components with Known Vulnerabilities), an attacker usually inject malicious data into form fields of websites. As these attacks are very common, using form fields as a honeypot component allows a honeypot to detect many attackers and many different attacks. B.Hive transparently injects form fields into existing forms of the target application. To do so, B.Hive acts as a proxy between Internet and target web application. It intercepts web pages served by the target web application and modifies forms if present. Additional form fields are added to detected forms. Changes to these additional form fields are monitored to detect attackers inserting malicious data to test for common vulnerabilities (e.g. A1, A3, A8, A9, see above). As field manipulation is usually part of early phases of an attack (reconnaissance phase), detecting attacks at this point of time helps to monitor attacks. The fields injected by B.Hive can for example be hidden fields, or the fields are made invisible using CSS or JavaScript. In all cases, these fields are invisible to legitimate users of the web application. B.Hive also intercepts incoming HTTP requests to the target application and removes the injected fields again. Hence, B.Hive is invisible for the web application as well as legitimate users. There is no impact on the functionality of the web application.

The crucial point in injection fields into existing form field is to find suitable names and default values for the injected form fields. Most web applications use a consistent naming of form fields of a form, and the naming is consistent with the context of the web application. Hence, using random names as well as using the same name all the time is prohibitive. Involving web developers or administrators to define suitable field names for security components opposes the goal to build a zero configuration honeypot suitable for a large number of frameworks. It is the main contribution of this paper to propose a way to select suitable form field names and field parameters for the injected form fields. B.Hive selects suitable form fields and other parameters from a database of form fields harvested from a large number of existing applications. B.Hive detects the context of a form and selects a suitable field name and field parameters from this database.

Related Work

There are some approaches that use real applications to construct honeypots, for example [START_REF] Mueter | A generic toolkit for converting web applications into high-interaction honeypots[END_REF]. However, the honeypot is directly integrated into the target application. Changing existing, already deployed applications is not desirable in a productive environment with already deployed applications. In contrast, B.Hive does not require changes of the target application. [START_REF] John | Heat-seeking honeypots[END_REF] describes an automated honeypot generation using search engines output. The resulting honeypot is a standalone non-productive web application. B.Hive in contrast protects an existing, productive web application.

Injection form fields in a form was already described in [START_REF]Squiid: Honeypot: Protecting web forms * Squiid[END_REF][START_REF] Perry | Honeypot Technique of Blocking Spam -Dex Media[END_REF]. However, the developer has to implement these fields on his own in the target application or using jQuery. In both cases, the undetectability of the honeypot heavily depends on the developer to select suitable form field names and parameters. B.Hive does not need any configuration to adopt the look and feel from the original web application, hence relieves the developer from the burden of selecting suitable form field names and parameters. The approach in [START_REF] Nassar | Method for two dimensional honeypot in a web application[END_REF] also uses form fields as honeypot. In this case, form fields are duplicated and it is disguised, which is the form field to use. For a human, such a form is easy to spot. B.Hive in contrast puts special emphasize on staying undetected.

In comparison to related approaches, the presented zero configuration honeypot solution has the advantage that it integrates into the target application without the need of configuration. The integration is almost independent of target application technology, framework or system. The injected form fields adapt to the context of the web page in which they are injected to stay unnoticed even from manual inspection of the web page by a human attacker.

Design and Implementation

This Section describes the design of B.Hive with a special focus on the generation of suitable form fields for the forms to protect.

Generation of Plausible Fields

The goal of the form field generation is to generate a form field for injection that is plausible in the context of the form where it should be inserted. Plausible means that attackers as well as automated attack tools cannot distinguish inserted fields from original fields of the form. B.Hive tries to find plausible fields in a database of web forms harvested from the 10,000 most popular websites according to Alexa [START_REF] Internet | Alexa -The Web Information Company[END_REF]. Important key figures of the Global Top 10,000 list of Alexa are described in Table 1. For the purpose of optimized storage, the extracted form data gets preprocessed. In a first step, the attribute name, the field name (f ), is extracted from every field. This attribute gets normalized as described in equation 1 where a character at index i in f is described as c i . Ξ denotes a technical control character for further usage in B.Hive, Θ stands for an alphabet of lowercase letters, and Υ names an alphabet of uppercase letters. Allowed other characters are termed by ϑ. Let u(x) be the function to bring an uppercase character to lowercase. The function h(x) is used for preprocessing.

For 0 ≤ i < length(f ) h(c i ) =                c i ,if c i ∈ Θ ∨ c i ∈ ϑ u(c i ) ,if c i ∈ Υ Ξ ,if (i -1 = 0 ∧ c i-1 = Ξ ∧ c i-1 = ∅) ∨(i -1 = 0) ∅ ,other (1)
Whenever h(x) = ∅, it will be ignored in further calculation. The result of this preprocessing gets stored in the new attribute f clean .

The condition b(x) to store f clean in the B.Hive database is described in equation 2.

b(f

clean ) = true ,if length(f ) > 0 ∧ f clean = {Ξ} f alse ,other (2)
The final result f clean is stored in a special Trie-structure (see [START_REF] Wang | Automatic Filling Forms of Deep Web Entries Based on Ontology[END_REF] for details), optimized for calculation operations with the Levenshtein Distance [START_REF] Levenshtein | Binary Codes Capable of Correcting Deletions, Insertions and Reversals[END_REF]. The Levenshtein Distance is used in B.Hive as a metrics for similarity between field names. The Levenshtein Distance is defined as "Minimum number of insertion, deletion and substitution edits required to change one word into another" [START_REF] Levenshtein | Binary Codes Capable of Correcting Deletions, Insertions and Reversals[END_REF]. It is ideal to handle typical abbreviations used by web application developers, e.g. to compare field names like "passwd" and "password". Formally the Levenshtein Distance lev(r, s) is defined in equation 3, using a search word s and a reference word r as input. The search word is compared to the reference word. The recursive function of lev(r, s) is k(|r|, |s|).

ω 1 (i, j) = max(i, j) ω 2 (i, j) = min(k(i -1, j) + 1, k(i, j -1) + 1), k(i -1, j -1) + 0) ω 3 (i, j) = min(k(i -1, j) + 1, k(i, j -1) + 1, k(i -1, j -1) + 1) k(i, j) =      ω 1 (i, j) ,if min(i, j) = 0 ω 2 (i, j) ,if min(i, j) = 0 ∧ r[i] = s[j] ω 3 (i, j) ,other (3)
The Trie-structure holds the preprocessed field names extracted from the Alexa Global Top 10,000 list. At the end of a field name (the last node in a Trie-structure) a link to the original field(s) is stored. Other parameters like field default values, raw HTML code, forms, and pages are stored in a separate database.

During run-time, the honeypot generator needs to find plausible form field names for the form fields that should be injected into forms in the output of the target application. Plausible means that attackers as well as automated attack tools cannot distinguish inserted fields from original fields of the form. This is done by finding forms in the candidate pool, which have similar form field names to the original response. B.Hive includes a LR-Parser with a state machine to extract form field names from the response. This means the full HTML source gets parsed. While parsing, it recognizes each form and each field of a form with its attributes. These forms and their form fields will be further used as input for B.Hive.

To find similar forms, it is necessary to define the similarity of field names (see equation 4). A field name is described with f and the length of f with l(f ). Φ is the set of all field names. Let Φ = {f 1 , f 2 , . . . , f n }. A form F is described as F ⊆ Φ and the set of forms is denoted by Γ where Γ = {F 1 , F 2 , . . . , F n }. λ is a system parameter for tuning performance and precision. It describes the maximum acceptable Levenshtein Distance. The other system parameter δ ensures that short field names (shorter than δ + λ) get compared with a lower Levenshtein Distance than longer field names. The key variable for the upper bound of similarity (what is least similar) is denoted by µ.

µ =      λ ,if min(l(f 1 ), l(f 2 )) ≥ δ + λ min(l(f 1 ), l(f 2 ) -λ ,if δ ≤ min(l(f 1 ), l(f 2 )) < δ + λ 0 ,other
For the similarity between two fields f 1 , f 2 let

f 1 ∼ f 2 ⇔ lev(f 1 , f 2 ) ≤ µ (4)
The calculation for the best matching form is described in equation 5. Based on the similarity between field names, the definition of similarity between two Forms F 1 and F 2 is:

F 1 ∼ F 2 ⇔ {∃f 1 ∈ F 1 ∃f 2 ∈ F 2 : f 1 ∼ f 2 }. The function a(F 1 , F 2 ) describes the number of similar fields in F 1 , F 2 where: a(F 1 , F 2 ) = |{f 1 ∈ F 1 |∃f 2 ∈ F 2 : f 1 ∼ f 2 }|.
Further, the number of similar forms with a field similar to f is defined as s(f ) where: s(f ) = F ∈Γ a({f }, F ). The set of different forms is denoted by Ψ (in contrast to Γ that could include similar forms). Ψ is defined as:

Ψ := {F 1 ∈ Γ |∃f 1 ∈ F 1 ∀F 2 ∈ Γ F 1 : ∀f 2 ∈ F 2 : lev(f 1 , f 2 ) > 0}.
To identify the best matching form Ψ Best for a reference form R (the form of the target application that should be protected) equation 5 is used.

Ψ Best = {F 1 ∈ Ψ |∀F 2 ∈ Ψ : a(R, F 1 ) ≥ a(R, F 2 )} (5)
In the last step, possible plausible fields for injection are identified. First, possible candidate fields Ω for injection are collected where:

Ω = {f ∈ ∪ F ∈Ψ Best F |∀r ∈ R : lev(r, f ) > 0}.
Let L [1] be the list of field names of Ω descendingly ordered by the number of appearances in similar forms: L [1] = {f 1 , f 2 , . . . , f n }. Such that: i < j ⇒ s(f i ) ≥ s(f j )).

Let L [2] be the list of field names of Ω descendingly ordered by the minimum Levenshtein Distance to any of the fields of the form in that the plausible field should be inserted: L [2] = {f 1 , f 2 , . . . , f n }. Such that: i

< j ⇒ lev min (f i , R) ≥ lev min (f j , R) where lev min (f, R) = min r∈R (lev(f, r) The index of f in L k is de- noted by index k (f ).
The result score score(f ) for a field f is defined by: score(f ) = (α * index 1 (f )) + (β * index 2 (f )) where α, β are factors to weight the ordering of L [1] and L [2] . In this approach, let α = β = 1 List L [3] is the list of the field names of Ω ascendingly sorted by the result score score(f ). L [3]

= {f 1 , f 2 , . . . , f n }. Such that: i < j ⇒ score(f 1 ) ≤ score(f 2 ).
The field with the lowest score(f ), respectively the first field in L [3] , is selected by B.Hive as the most plausible field name.

Position of Form Fields

For the injected field to be unnoticed, it is necessary to find a plausible position of the injected form field in the form. B.Hive will inject the honeypot field at a position in the target form F than is similar to the position in the form H from that the honeypot field was harvested.

L [H] is a list of field names from form H ascendingly ordered by the index of the field names in H: L [H] = (h 1 , h 2 , . . . , h i ). L [F ] defines a similar list for the form F : L [F ] = (f 1 , f 2 , . . . , f i ). Let h k be the honeypot field to inject into the target form F . Let l be the index, where |l -k| is minimal and ∃m : f m ∼ h l . The result form is defined in equation 6:

L [F ] = (f 1 , f 2 , . . . , f m-1 , h k , f m , . . . , f j ) ,if l -k ≥ 0 (f 1 , f 2 , . . . , f m , h k , f m+1 , . . . , f j ) ,if l -k < 0 (6)

Field Type and Default Value

In most of the cases from the Alexa Top 10,000 the type of a fields with the same name is the same. Hence, it is possible to let the injected field have the same type and default value as any one of the fields in the database. B.Hive injects the honeypot field using the same type and default value it had in the form from which it was originally harvested. The fields are hidden by hidden attribute. Whenever the field from the result form contains an id, the honeypot field will get this id too, except this id already occurs in the original page. The algorithm for the ordering of the attributes is naive but effective. B.Hive computes the most frequently used ordering from the original page. As ordering attributes, name, value,id and style is used. The injected form field gets constructed with this ordering.

Evaluation

This chapter provides the evaluation results of B.Hive. First, the choice of system parameters for the evaluation is presented. Subsection 5.2 evaluates the effectiveness of B.Hive. The following subsection evaluates the quality of the honeypot. The last subsection evaluates the performance of B.Hive. Every analysis uses the full set of data without snipping outliers. For the sake of readability, histograms only show forms with less then 16 fields. Only 292 out of the 15,255 harvested forms have more than 15 fields.

Choice of System Parameters

The most relevant system parameter for the performance and the effectiveness of the honeypot is the maximum edit distance λ. When choosing λ there are two computing factors: Whenever the allowed Levenshtein Distance grows, the similarity check gets more accurate but the performance drops.

For the evaluation, one honeypot field for every Alexa Top 10,000 has been generated with different values for λ in the range {0, 1, . . . , 5}. Table 2 shows the resulting run-time as well as the percentage of cases where no plausible field could be found for different values of λ. B.Hive has been started single threaded with a sequential calculation.

A value of λ = 3 was chosen for all other evaluations as it provides a balanced result for run-time and success rate. The system parameter δ was set to δ = 3. Changing this parameter to a lower variable has no significant changes in the accuracy, but the subjective quality of honeypot fields drops in some cases. The subjective quality has been measured with a manual validation of the results.

Evaluation of Effectiveness

To prove that it is possible to generate honeypot fields for most existing web application, B.Hive was used to generate honeypot fields for each website of the Alexa Top 10,000 (list of most popular websites worldwide). Table 3 shows the results: A significant number of forms (96.22 % of all forms) can be protected by B.Hive. Successful protection of a form means in this context, that at least one plausible field was found for the form. B.Hive keeps a list of unprotectable forms. Whenever there is no plausible field for a form (3.78 % of all forms), B.Hive takes a random field from the list of unprotectable forms. In the following evaluation, this is not regarded as success.

The evaluation of the effectiveness shows, that in average there are 2.5 similar fields in the target form and the form from which a honeypot field is taken. In average, for each form there are 1023.4 possible honeypot fields. Figure 1 and Figure 2 describes these results in detail. Figure 1 gives a more detailed view on the similarity of fields. This figure shows the similarity between the target form and the result form for each form in a site of the Alexa Top 10,000 list. This and all further histograms use less equal calculation. This means that the upper right corner of a bin represents the value. Figure 1 has the number of fields in the reference form (target form) on the x-axis. On the y-axis the number of fields in the similar form (the form from which the honeypot field was chosen by B.Hive) is given. The bins and their colors represent the number of occurrences of a combination.

Figure 2 shows the number of potential honeypot fields per target form for all forms of the Alexa Top 10,000 list. The x-axis describes the number of fields in the target form. The y-axis shows the number of potential honeypot fields for this form. The color denotes the number of occurrences of this combination. It could be seen that there is a significant number of potential honeypot fields for all but very small forms (forms with only one field).

In conclusion B.Hive is able to generate a proper protection for the vast majority of the most popular 10,000 web sites.

Evaluation of Honeypot Quality

It is one of the main goals of the work presented in this paper to keep an attacker unaware of the presence of the honeypot. Hence, it is very important, that humans (attackers) cannot identify the injected form fields when manually inspecting the HTML source code of a page. To evaluate, if attackers can identify injected form fields, an empirical study with 75 participants was executed. All participants are students in a computer science program (49 in a bachelor program, 26 in a master program). Participants of the study were presented the content of 50 different forms of the Alexa Top 10,000 list. With a probability of 0.5, a form field was injected by B.Hive, in the other cases the original form was presented. The students were told before that 50% of all forms include an injected field. The students were asked to identify injected form fields or to state that there is no injected field in a form. The default answer for each form was "I do not want to answer" to make sure, that no "click-through" influences the results. Table 4 summarizes the setting. The students decided in 1,919 cases (51.67%) that a form includes an injected field. In 1,013 cases (52.79% or 27.28% of all choices) they were right and in 906 cases(47.21% or 24.39% of all choices) they were wrong. In 1,675 cases (45.1%) the students decided that no injected field was present. In 825 cases (49.25% or 22.21% of all choices) they were correct and in 850 cases (50.75% or 22.89% of all choices) they were wrong. In the remaining 120 cases (3.23% of all choices) the students did not want to answer. In average, the students chose in 24.745 (out of 50) cases (49.49%) the correct answer (field injected or not). The standard deviation for a correct answer is 6.74 with a maximum of 35 correct answers and a minimum of 1 correct answer.

These results are significantly near random choices, hence showing that it is not possible for an attacker to identify the injected form fields when looking at the field names.

In 314 cases the injected field was detected. In average the students decided in 4.077 (out of 50) cases (8.154%) for the injected field and in median they decided in 3 cases for the injected field. The standard deviation is 2.818 with a maximum of 12 correct answers and a minimum of 0 correct answers for all student and 50 answers. With random choices the probability to detect the honeypot field is 10.748% (with 4.8 fields per form in average when a field was injected).

This result is also significantly near random choices. There has been no significant difference between master and bachelor students.

In conclusion, the evaluation shows that B.Hive is able to hide itself in the vast majority of forms. Humans cannot successfully identify the injected form fields.

In order to show that B.Hive is useful for detecting automated attacks, and that attack tools do not avoid the fields injected by B.Hive, the breakable web application (BREW) [START_REF] Pohl | BREW: A breakable web application[END_REF] was augmented with B.Hive and then attacked using penetration testing tools Owasp Zed Attack Proxy Project (Owasp ZAP) [START_REF]Owasp: OWASP Zed Attack Proxy Project -OWASP[END_REF] and Vega [START_REF] Subgraph | Vega Vulnerability Scanner[END_REF].

In average, each form of BREW has about 2.43 fields. In conclusion it is expected that a penetration testing tool will hit the honeypot field with about 40% of all requests. Table 5 concludes the result in one overview. In all cases B.Hive worked correct and the penetration testing tools identified all B.Hive fields as possible target. The row touch quota describes the expected calls to the honeypot when the penetrations testing tool identify the honeypot as suitable target.

In conclusion, each penetration testing tool recognized the injected honeypot field as a possible target. Both tools showed the expected amount of attacks on the target. B.Hive was able to recognize and identify each attack.

Performance Evaluation

B.Hive works as a proxy for web applications, so all traffic to the target application passes B.Hive. Hence, it is important to evaluate if B.Hive is ready for productive usage. In contrast, Figure 6 shows B.Hive under productive usage with enabled caching and with parsing.

Figure 3 shows the run-time for B.Hive for forms of the Alexa Top 10,000 list with a different number of fields in them. The x-axis shows the number of fields in the target form. The y-axis shows the run-time in seconds to find a similar field. The colored bins describes the number of appearance for this combination. It can be seen that B.Hive is able to protect a new website with a proper run-time. The vast majority of forms can be protected under 0.5 seconds. The average run-time for B.Hive is 0.46 seconds. However, for productive usage, it is highly recommended to use caching for optimized run-time.

Figure 4 shows the run-time for B.Hive with different number of form fields in the target form. The search words used are randomized strings with a length of ten characters. It is guaranteed that the field names of the target form have no similarity to any other word in the database. This avoids side effects during result set building. Every number of field names has been measured 100 times. The x-axis describes the number of reference words per evaluation. The y-axis shows the run-time of B.Hive. The color denotes the number of occurrences of this combination.

The evaluation shows that the run-time grows near linear with the number of form fields in the target form, hence protecting forms with a low number of fields is faster then protecting forms with a high number of field. Fortunately, the evaluation of the Alexa Top 10,000 showed, that the average number of fields per form is very low (average of 3.8).

Figure 5 shows the dependency between the run-time of B.Hive and the length of one field name. The x-axis shows the length a of field name. The y-axis The B.Hive algorithm is designed with the possibility of multi-threading. Each form field name analysis is atomic, a number of form field names (forms with more fields) can be calculated in a parallel way. The result set assembling is designed that algorithm like map reduce [START_REF] Dean | Mapreduce: simplified data processing on large clusters[END_REF] can be used.

In conclusion, the performance evaluation shows that without caching (or the protection of a new form, not known to the cache) B.Hive is able to protect a web application in productive usage.

Figure 6 shows B.Hive in a productive scenario: caching and parsing is enabled. Injected form fields get cached and further injections do not have to run the algorithm again but can look up a suitable field in the cache. The x-axis of the figure shows the number of characters for each page. The y-axis shows the measured run-time for each page. The colored bins shows the number of appearances of each combination. The figure shows the correlation between the number of characters in the raw HTML page and the runtime, which is near linear. In average, B.Hive needs 30.5258 milliseconds to protect one page, which is 15.072 times faster than without caching. The number of forms per page does not correlate with the runtime. The overhead to query the cache (measured without parsing) is insignificant with 0.000072 milliseconds in average.

The honeypot field generation for one page is done by a single process. A load balancing with more processes or different server can be done by starting more instances of B.Hive and a load balancer like nginx [START_REF] Sysoev | nginx[END_REF].

In conclusion, B.Hive is able to protect even large and busy web applications when using caching and parsing.

Conclusion and Outlook

This paper presents B.Hive, a honeypot that protects existing web applications in productive use by transparently adding form fields to forms with a special focus on the undetectability of the honeypot by human inspection. The evaluation of B.Hive shows that humans are not able to identify the injected form fields, hence an attacker cannot avoid the honeypot. This allows to gain valuable insights into attacks. The evaluation also showed, that B.Hive only adds a slight overhead to the total response time of a web application when using caching and parsing. It also shows that B.Hive can protect the vast majority of web applications.

Over the course of the next year we plan to deploy B.Hive on a public web server to gather data on how real attackers interact with it. This could also lead to classification of attack payloads. Future work includes a extension of B.Hive beyond form field injection.

Fig. 2 :

 2 Fig. 1: Field similarity metric

Figure 3 ,

 3 4 and 5 show the performance of B.Hive without caching and without the overhead of parsing.

Fig. 3 :

 3 Fig. 3: Run-time of B.Hive without caching and without overhead of parsing

Fig. 4 :

 4 Fig. 4: Performance number of search words

Fig. 5 :

 5 Fig. 5: Performance diff. word length

Fig. 6 :

 6 Fig. 6: Performance with caching and with parsing

Table 1 :

 1 Initial database for Alexa Global Top 10,000

	Websites	10,000
	Extracted forms	15,255
	Different field names	18,210
	Average fields per form 3.8
	Maximum fields per form 182
	Minimum fields per form 0

Table 2 :

 2 Percentage of cases in which no plausible field could be found and run-time for different values of λ

	λ No result ∅ run-time sec
	0 9.34%	0.026
	1 6.90%	0.079
	2 5.20%	0.227
	3 3.78%	0.459
	4 2.64%	0.731
	5 1.99%	1.027

Table 3 :

 3 Results of the Evaluation of Effectiveness of B.Hive when protecting each website of the Alexa Top 10,000 list

	Number of forms	15,255
	Trie-Nodes	140,298
	Field names	18,210
	Protectable forms	146,790 ∼96.22%
	∅ similar fields	2.5
	∅ possible honeypot fields / form 1,023.4

Table 4 :

 4 Empirical study setting

	Students	75
	Evaluated number of forms 3,714
	Forms without honeypot	1,798 (48.41%)
	Forms with honeypot	1,916 (51.59%)

Table 5 :

 5 Validation with penetration testing tools

		Owasp ZAP Vega
	Requests	783	2,097 2,880
	Post Requests	524	814 1,338
	Trapped Requests 206	342 548
	Touch quota	99%	101% 100%