# Secure Remote Storage of Logs with Search Capabilities
## 3 Related Work
The encryption algorithm also enables forward integrity, meaning that, if an attacker can compromise the log data at instant \(t\), all log data stored prior to \(t\) will not be compromised. Integrity is guaranteed by the construction of an hash chain composed by message authentication codes that are calculated per entry and based on a secret random value. Uniqueness is ensured by the use of timestamps, which also prevent replay attacks. Based on Reference [84, 85], [PERSON] designed BBox [86], a digital black box that added asymmetric cryptography to guarantee the authenticity of log records. It assures a reliable data origin by only considering log records from legitimate sources. The log records, in order to guarantee forward secrecy, are stored in a encrypted state. Each log is encrypted with a randomly generated key. Tamper-evidence is accomplished through the maintenance of an hash chain. BBox allows single keyword searches, with the use of log views, a mechanism similar to views of relational databases. [PERSON] et al. [87] proposed a technique to protect log records from tampering based on a system of linear equations, while still permitting search operations to be conducted over those records. The scheme is comprised of four functions: \(KeyGen(s)\) that returns a key pair \((PU,PR)\) using a security parameter \(s\); \(PKE(PU,m)\) that encrypts a message \(m\), using \(PU\), and outputs \(s\); \(Trapdoor(PR,m)\) that outputs the trapdoor \(t\) using \(m\) and \(PR\) as input; and a test function that verifies if an encrypted keyword is present in the log records. This verification is conducted using a generalization of the inverse matrix concept [88]. More recently, [PERSON] et al. address encrypted log searching while preserving privacy [89] using access tickets that are computed using an hash function that contains: the identity and the IP address of the requesting user, the request expiration date, and information regarding the type of operation desired to be executed over the data. This information is then used on the construction of the keyword set that is appended to the encrypted audit log and enables the server to answer each one of the \"who/when/where/what\" data owner queries. When the data owner desires to query his encrypted audit logs, it creates a trapdoor of the keywords of interest by applying the same algorithm used on the audit log generation. The master keys are used on this generation, assuring that no one besides the data owner can create search trapdoors. Upon receiving such trapdoors, the server tests them against each stored log record. All matching results are returned to the data owner, whom, after assuring the validity and integrity of such results, decrypts them and obtains the information regarding the kind of access that has been done over his data. Table 1 compares the identified related work. Except [PERSON] et al. [65], whose scheme is focused on the transmission phase, all identified solutions enable privacy by encrypting the data prior to its storage. Boolean search refers to the capability of using the \"AND\", \"OR\", and \"NOT\" operators. Almost all solutions enable data integrity and authenticity with the use of a cryptographic hash chain. Only [PERSON] et al. [71] devises a different approach with their specific technique named FssAgg. Regarding encrypted log searching, the solution proposed by [PERSON] et al. [79], although source of inspiration for subsequent solutions, only supports single keyword search and has both high computational and storage costs. The solutions proposed by [PERSON] et al. [86] and [PERSON] et al. [87], while being more efficient, only allow for single keyword search. [PERSON] et al. [82] enhances the search capability with support for the \"AND\" and \"OR\" operators. Nevertheless, this Boolean queries are achieved not by performing Boolean operations but by adding extra searchable indexes. [PERSON] uses BF that admit the occurrence of false positives, which might disclose more log records than the ones that are relevant. [PERSON] et al.