# Secure Remote Storage of Logs with Search Capabilities
## 4 Proposed Solution
### Initialization  
The initialization operation is comprised of two distinct actions. The first is the setup of the SLS itself, and the second is the setup of every source of log records (\(LS\)) and its integration with the SLS. We assumed that a source of log records corresponds to a file watcher that only forwards data from one client application.  
The setup of the SLS starts by the computation of a pair of asymmetric keys (\(SLS_{pubK}\) and \(SLS_{privK}\)) to assure a confidential and authenticated communication between the SLS and the SLaS Application. The SLaS Application also computes a set of asymmetric keys (\(SLS_{pubK}\) and \(SLS_{privK}\)) and performs an handshake with the SLS. This handshake consists of the exchange of the public keys of both entities in order to implement an authentication system between them. Additionally, a symmetric key \(SLS_{kK}\) is randomly generated by the SLS to be used in the trapdoors creation.  
The setup of a \(LS\) starts by the configuration of its properties. If the log records follow a fixed structure, thus allowing field searching, a regular expression (\(LS_{regex}\)) can be configured in order to extract specific information from each log record. Alongside, a mapping of the extracted fields (\(LS_{map}\)) must be added. This mapping includes, for each field, its name and a unique identifier to be used on the cloud side, thus not revealing the type of each field. If the log records do not follow a fixed structure, the SLS will split each log record by a delimiter (e.g., space). Hence, a delimiter (\(LS_{dlm}\)) must be configured. Additionally, a set of blacklist characters (\(LS_{blk}\)) is added to allow the SLS to remove unwanted characters and to sanitize the log records prior to its storage.  
The following step of a \(LS\) setup is the generation of a unique identifier (\(LS_{i}\)). A pair of asymmetric keys (\(SLS_{pubK}\) and \(SLS_{privK}\)) is generated and will be used to assure confidentiality between the file watcher and the SLS. Then, three symmetric keys are computed. The first key, \(LS_{aK}\), is used for the calculation of HMACs that authenticate the file watcher against the SLS. The second key, \(LS_{hK}\), is used to compute each log record HMAC, creating an hash chain for integrity and authenticity validations. The third key, \(LS_{eK}\), is used to compute an encryption key \(K_{Ln}\) for each log record. A random seed value \(LS_{seed}\) is also computed in order to initialize the \(LS\) hash chain. \(LS_{i}\), \(SLS_{pubK}\), and \(LS_{aK}\) are shared with the file watcher.  
In order to support contextual and temporal privacy, either future privacy and past privacy, all relevant cryptographic material will compose a session context. The number of such session contexts and its duration is expected to be specified on a case-by-case basis. For instance, if its the case of a team of developers, within an organization, that are jointly working on a project, the session will be shared between them, and for the duration of the project. If it is the case of a client, a developer and a help-desk technician trying to debug an online service, a specific session context would be created for that purpose. Another case could be the one of a non-critical web application that does not log information with personal data, where a session context could be maintained for longer periods of time. The referred session context is comprised of \(SLSi_{pubK}\), \(SLSi_{privK}\), \(LS_{aK}\), \(LS_{hK}\), \(LS_{eK}\), and \(LS_{sect}\).