# Secure Remote Storage of Logs with Search Capabilities
## 4 Proposed Solution
### Indexing  
The Indexing operation is carried out by the SLS and per log record sent from the file watchers. The log data undergoes a series of cryptographic operations which transforms it into searchable encrypted information, as described in Algorithm 1. The first instruction of Algorithm 1 is the attainment of \(LSi\) properties (step 1). Next, a unique identifier \(L_{mi}\) is generated for log record \(L_{n}\) (step 2). This identifier forms the basis of the \(K_{Ln}\) computation (step 3), the key specifically used to encrypt the entire log record \(L_{n}\) alongside its timestamp \(TS\) (step 4). Afterwards, an HMAC \(H_{Ln}\) of the concatenation of \(LE_{n}\), \(LS_{i}\), and \(L_{ni}\) is calculated (step 5) in order to maintain both the integrity and authenticity of that specific log record. The obtained \(H_{Ln}\) is then used to produce the current log record hash chain link \(HC_{Ln}\) (step 6). \(HC_{Ln}\) consists of an HMAC of \(H_{Ln}\) concatenated with the previous log record hash chain link \(HC_{Ln-1}\). \(HC_{Ln}\) is set as the \(HC_{Ln-1}\) of that \(LS\), which will be used on the subsequent indexing operations (step 6). Following, the algorithm moves on to the preparation of the search capability. First, it creates an empty set of trapdoors \(T_{Ln}\) for that log record (step 7). \(T_{Ln}\) is populated with one of two ways. If the log record follows a fixed structure, and \(LS\) has a regular expression \(LS_{regex}\) configured (step 8), the log is parsed by that. If not, the log record is split by a pre-configured delimiter \(LS_{dlm}\) (step 16). More specifically, if \(LS_{regex}\) exists, for each extracted field \(L_{nfield}\) of the log record, a lookup operation is performed (step 12) in order to obtain the identifier \(L_{nfieldId}\) of such field. Then, the trapdoor \(L_{ntrapdoor}\) for that specific field is built by computing an HMAC, enabling its future search (step 13). Finally, a tuple containing \(L_{nfieldId}\) and \(L_{ntrapdoor}\) is added to \(T_{Ln}\) (step 14). If no \(LS_{regex}\) is configured, the log record is sanitized by the removal of the characters present in the configured blacklist \(LS_{blk}\) (step 17) and split by \(LS_{dlm}\) (step 18). Each part \(L_{nfield}\) of the split log corresponds to a keyword (step 20); thus, \(L_{ntrapdoor}\) for each of that keywords is built by computing an HMAC (step 21), which is then added to \(T_{Ln}\) (step 22), similar to what is done in the regular expression parsing mode. This information is, afterwards, transferred to the cloud, being stored by the SLaS Application in its database. Afterwards, the encrypted inverted index \(InvIndex\), which forms the basis of the forthcoming search operations, is updated. The content of each received trapdoor tuple \(T_{Ln}[i]\) is analyzed. If \(T_{Ln}[i]\) includes the field identifier \(L_{nfieldId}\), the \(InvIndex\) entry for the combination of \(L_{nfieldId}\) and \(L_{ntrapdoor}\) is affected. If \(T_{Ln}[i]\) is composed by \(L_{ntrapdoor}\) alone, only the \(InvIndex\) entry for \(L_{ntrapdoor}\) is influenced. In both situations, a verification is executed to find if \(T_{Ln}[i]\) already exists on \(InvIndex\). If this verification is successful, the respective \(L_{ni}\) is added to the set of the already existing identifiers.