# Secure Remote Storage of Logs with Search Capabilities
## 4 Proposed Solution
### Indexing
```
Input :\(Q\) Output :\(QE_{terms},QE_{ops}\)
1\(Q\)\(E_{terms}\leftarrow\)[]
2\(Q\)\(E_{operatos}\leftarrow\)[]
3\(Q_{parsed}\leftarrow\) splitQuery(\(Q\))
4 for\(i\gets 0\)to length(\(Q_{parsed}\))do
5\(Q_{part}\gets Q_{parsed}[i]\)
6 ifisNestedQuery(\(Q_{part}\)then
7 BuildQuery(\(Q_{part}\))
8 elseifisOperator(\(Q_{part}\))then
9\(QE_{operatos}\).add(\(Q_{part}\))
10 else
11 ifexists(\(Q_{part}\).\(Q_{name}\))then
12\(Q_{fieldId}\gets LS_{map}\).convert(\(Q_{part}\).\(Q_{name}\))
13\(Q_{trapdoor}\leftarrow\) HMAC.create(\(SLS_{KK}\), \(Q_{part}\).\(Q_{value}\))
14\(Q\)\(E_{terms}\).add((\(Q_{fieldId}\), \(Q_{trapdoor}\)))
15 else
16\(Q_{trapdoor}\leftarrow\) HMAC.create(\(SLS_{KK}\), \(Q_{part}\).\(Q_{value}\))
17\(Q\)\(E_{terms}\).add((\(Q_{trapdoor}\)))
```

**Algorithm 2** SLS query builder algorithm

```
Input :\(QE_{terms},QE_{ops}\) Output :- Let \(L\gets SLaS\).search(\(QE_{terms},QE_{ops}\))
1 for\(n\gets 0\)to length(\(LE\))do
2\(L_{ni},LE_{n},H_{Ln},LS_{i}\gets LE[n]\)
3\(LS\leftarrow\) LogSources.get(\(LS_{i}\))
4\(\log\)Verified \(\leftarrow\) HMAC.verify(\(LS.LS_{RK}\), \(LE_{n}+LS_{i}+L_{ni}\), \(H_{Ln}\))
5 iflogVerifiedthen
6\(K_{Ln}\leftarrow\) HMAC.create(\(LS.LS_{eK}\), \(L_{ni}\))
7\(L_{n},TS\gets K_{Ln}\).decrypt(\(LE_{n}\))
8\(SLS\).print(\(L_{n},TS\))
```

**Algorithm 3** SLS search algorithm

## 5 Validation

A prototype of the proposed solution was implemented using version 12.6.0 of the NodeJS runtime environment. All cryptographic operations used the _crypto_ native module, which provided methods to implement the solution with secure cryptographic algorithms. The tests performed used the AES algorithm in the GCM scheme [90]. The HMAC computations were based on the SHA-3 algorithm [91]. The asymmetric cryptography applied on the communication phase used the RSA [92] algorithm. In terms of hardware, the prototype was executed on a computer running Linux with an _Intel Core i7 4700 MQ 3.4 Gltz_ processor and 8 GB of _DDR3 RAM_ memory. For storage, both a single instance of a _MongoDB_ and a _PostgreSQL_ database servers were adopted. Moreover, during the prototype development, we assume the existence of a single log source. The performance tests were executed using a real-life access log from a publicly accessible web server with, about, thirty thousand (30,000) records per day, on average. Despite the fact that the proposed solution supports any type of log files, this log was select due to being readily available. The average number of records per day was calculated from a period of three weeks. The log files were segmented by day and the number of log records per day was counted and then averaged. The tests were performed using a combination of different key sizes for the two algorithms used in indexing and searching operations. Experiments were performed with AES with 128, 192, and 256 bit size keys and SHA-3 with 256, 384, and 512 bit size keys. For the RSA keys, since it was only applied on the communication between the SLS and SLaS Application, a unique size of 2048 bits was used. In particular, tests were carried out with the following combinations: AES 128 and SHA-3 256; AES 192 and SHA-3 384; AES 256 and SHA-3 512. In each experiment, three test runs per each key size combination were carried out and the average values presented. The first set of tests focused on time elapsed for the indexing of the 30,000 log records and the storage space it required when using multiple combinations of keys sizes of the AES and SHA-3 algorithms. As illustrated in Figure 4, when using the minimum key sizes of 128 bits for AES and 256 for SHA-3, the proposed solution can index the required log entries in 815 s. The medium key sizes of 192 bits for AES and 384 for SHA-3 are the ones that take longer, demanding 823 s. When using maximum key size of 256 bits for AES and 512 for SHA-3, the proposed solution takes 818 s (roughly 13 min) to do the same operation.