# A Secure Auditable Remote Registry Pattern for IoT Systems
## 4 The Secure Auditable Registry Based On Message-Oriented Middleware (SARMOM) Pattern
### Implementation  
As stated above, a proper context for the \(\mathrm{SARMOM}\) pattern requires a Message-Oriented Middleware to decouple the secure registry from the target IT system. Even though there are several middleware solutions capable of event streaming, we will refer to Kafka for describing the most relevant implementation considerations that the pattern adopter must take into account. The conclusions in this section are also valid for other MOM implementations. One key aspect is complexity of configuration and management. Since Kafka supports a distributed operation but only handles the actual data streams and connectivity to clients, a configuration manager component is required. Prior to version 2.8, the Kafka cluster required Zookeeper to manage its configuration. In April 2021, Kafka became self-sufficient, simplifying the architecture by consolidating all configuration management into Kafka itself. Kafka also provides a set of key-value pairs in a properties file for configuration, which can be supplied either from a file or programmatically. There is a high number of supported properties, which are out of the scope of this work, allowing to configure any aspect or behavior of the middleware: brokers, topics, producers, consumers, connectivity, streams, etc. The flexibility and versatility of Kafka makes it an excellent choice for many domains, and, consequently, there is a huge ecosystem around it. These properties make Kafka complex to manage (see Refs. [38; 39] for details). The security of the SAR component is also very dependent on the way this component is implemented. The main aspects to consider are the security of the hash chaining system and the security of the registry storage. The ideal implementation for this is to apply a  
Figure 5: System architecture after applying the \(\mathrm{SARMOM}\) pattern. -chained-hash approach [40], in which each record includes the secure hash of the previous record, similarly to what is done with blockchain technologies but without the need to have an infrastructure of peers, conflict resolution, distributed verification, etc. As already mentioned, additional security mechanisms (encryption, anonymization, pseudonymization, redundancy, etc.) can be adopted, depending on the specific requirements of the record contents. The service must also provide secure storage for the records. The interfaces of the SAR component must be designed not to provide any modification or deletion functions. Only append and read interfaces must be provided. Error handling in this setting must be done by appending error-detection and eventually error-correction events. For instance, a slot machine may report wrong values for its meters (in the gambling domain, meters record things like the amount of money cashed in and out, the number of games played, etc.). When this is detected, the system is not allowed to change the records stored in the registry to reflect the correct values. Instead, new error-detection and error-correction records are inserted, to allow client services to reconstruct the correct state of the system. In this way, the authenticity of the events and the accuracy of the state of the system are guaranteed and can be proved. Two main read interfaces must, at least, be included. One is a filtered querying interface (FilteredEventQuerying) specifically tailored for the auditing authorities to access (read) the registry contents that are relevant for their role while respecting the privacy requirements. The other one is an unfiltered querying interface, allowing unrestricted read access to the registry contents for the management of the system (named SUD Management in the figure). Please note that this is a conceptual definition of the interface, but, normally, the unfiltered querying interface will be implemented by means of smaller interfaces, which may be restricted for some management functions that do not require full access, following the Interface Segregation Principle.