A Novel Reputation System for Mobile App Stores Using Blockchain

With thousands of mobile applications submitted to online application stores, the mobile application market has experienced significant growth. This growth is accompanied by an increase in malware presence. A possible solution would be to leverage those reports across all mobile ecosystems, creating a shared reputation system.

code that hardens automated code analysis. Studying their behavior during execution is not feasible due to the prohibitive costs and high inefficiency. This shows how a centralized approach to cybersecurity may not be the only answer to fight mobile malware, where each app store has its own methods and does not share the discovered threats.
A new approach to this problem is to relate the multiple actions of millions of users and thousands of developers (reputation events), such as ratings, comments, or app uploads, to a degree of trust and use that found reputation in the cybersecurity processes to provide trustworthy and relevant decision support to the quality assurance (QA) and security teams. Moreover, such an approach could benefit both the developers as they could switch between different markets while keeping their reputation and the consumers as it makes it easier for them to trust a new developer. This would significantly increase the content quality of all app stores, having a direct impact in their revenue, a practice that is widely adopted on e-commerce platforms, such as Amazon or eBay, among several others. 4,5 Building a consortium solution for several competing app stores presents several problems of performance, scalability, interoperability, data security, and trust between the entities. [6][7][8][9] These problems include 1) trust between the app stores inside of the consortium; 2) the scalability, interoperability, and performance to manage multiple actions of millions of users and thousands of developers, where several different app stores can contribute, and each one has its own business model and rules; 3) data privacy as the user's data need to be securely saved to comply with data regulations; 4) traceability as it is necessary to know the history of actions of the users; and 5) cost-efficiency.
Blockchain is a distributed ledger in a peer-to-peer network with unique characteristics that can effectively solve the security problems. 6 The new blocks are validated through a consensus protocol that also guarantees a total order of them. Blockchains can be public, private, or a mixture of both. In public blockchains, everyone can join the network and participate. Every node can mine the new block and is rewarded by the issuers of transactions inside that block. In private blockchains, only one entity controls the network and dictates who can join the network and read and write blocks. In this network, it is not necessary to pay mining fees. In consortium blockchains, the control of the network is shared among all participant entities, where everyone can read and write, but joining requires the approval of all members. As in private blockchains, there are no mining fees.
A possible solution to tackle the mentioned problems consists of using a blockchain integrated with a cloud system to support the blockchain with the necessary logic operations and provide an interface for the QA and security teams.
Aptoide, already considered one of the safest Android app stores, 2 has nonetheless felt the need to improve its security by developing such a system. Here, millions of users, through the app stores installed on their smartphones, perform reputation events that are disseminated through the blockchain's services. The app stores can then infer the threats on these applications through those reputation events and remove them, thus creating a mobile cyberphysical system (CPS) connecting millions of devices with blockchain and cloud/interface services.
This article presents a cloud-based solution to manage reputation events that are integrated with a consortium blockchain, to serve as a distributed ledger to store those events as the support for the reputation system. This combination allows for the identification of compromised apps through a dedicated interface for the analysts, where the apps classified as a threat by the high reputation users are displayed first for review. This provides an improvement on QA to users and mitigates the potential for privacy breaches and data theft for all users of the app stores who wish to be in the consor tium. This possibilit y gene r ate s a g loba l app e conomy w it h increased security, trust, and From the obtained evaluation results, it was observed how the combination of a cloud solution with a blockchain could improve this type of system regarding data security, interoperability, and scalability, while being cost-effective.

RELATED WORK AND BACKGROUND
Some works have already integrated blockchain in their reputation systems to overcome the problems mentioned. 8,10 Some examples follow.
Rep on the Roll 11 is a generalist reputation system for peer-to-peer networks, where blockchain is used for effective communication and information sharing between clients and whenever behavior traceability is desired. Both the trust and reputation of peers are maintained and unmodified due to the proprieties of blockchain. The authors compared their work with eBay, which can process an average of 23.184 transactions per second (TPS), against the modest quantity of 10 in their work. Such a low number comes from the time it takes to mine a block in a bitcoin-based blockchain. This is a performance problem as well as an opportunity for a denial of service attack, as the authors noted. This performance issue also makes the network hard to adopt and implement on larger scales since the resources required from each node are costly. The network is also public, which raises some data privacy concerns as all of the user's data are accessible on a public network.
SH-BlockCC 8 proposes a cloud solution based on blockchain to increase the security and trust of the Internet of Things (IoT) in smart homes while maintaining availability, scalability, and traceability. The authors demonstrated how their proposed architecture could make the IoT more secure and efficient. However, their blockchain is too tailored to their problem without providing clear implementation details, making it very difficult to translate it to other domains.
In k P rotocol 12 is a decent ra lized third-party software to handle a payment system for e-commerce marketplaces. The goal is to increase trustand therefore, security-by evaluating the transactions between the sellers and buyers to create reputation scores. This is very close to our goal. However, they require cryptocurrency, so the software is based on Ethereum, a public blockchain. As mentioned, this type of blockchain brings some performance and data privacy issues as well as the necessary mining fees.
Decentralized Science 13 is a blockchain-based distributed platform for science publications, together with a reputation system for peer reviewers. The platform is used to store the peer review process communications, where the smart contracts validate the system's rules. This system is also based on Ethereum.
Some other implementations and areas use the blockchain for storage and reputation management, such as an emissions trading scheme 14 with a private blockchain, where new participants must pay to adhere; the automobile industry, 15 where a public blockchain is used with an external service to provide the necessary security and data privacy; and CPS, 16 a bitcoin-based blockchain with extra work to offer the required CPS systems data privacy, among others.
None of the presented works can provide a truly scalable solution while ensuring data privacy. A possible solution is to use a consortium blockchain, which is a blockchain that is controlled by a set of trusted entities, not entirely public or entirely private. This approach brings several benefits to the collaborations between organizations besides security, namely, scalability (it is easy to add new nodes and other app stores) and data privacy (only authorized app stores can access the data). 7,17 The solution is still cost-effective 7,8,18 since there is no need to pay the mining fees as is done for public blockchains, and the maintenance costs can be equally shared between all participant entities. The consortium approach also adds the necessary trust between entities in the app market since no one fully controls the network or can tamper with the data unnoticeably.
Some works already demonstrate the usefulness of such an approach, 4 where the authors used a consortium blockchain combined with a common database for asset trading. Here, the reputation is computed inside of the network on a smart contract. This makes it impossible to adjust to the specific needs of each new entity, a desirable property for the app market ecosystem. Also, the use of a common database demonstrates the need for a balance between the cloud and a blockchain.
To implement a consortium blockchain, we selected the Hyperledger Fabric (HLF), 19 a blockchain framework under the umbrella of the Hyperledger Greenhouse, hosted by The Linux Foundation. It was chosen due to its strong modularity, widespread adoption, popularity, 17 and proven scalability properties, 7 besides providing all of the mentioned requirements. 19 HLF has three distinct phases. The execute phase, which starts when a client submits a new transaction to the endorsement peers, runs the chaincode (equivalent to smart contracts), creating the read-write (RW) sets. Defined by the endorsement policy, these peers are the only ones that can simulate new transactions. This set is then returned to the client, which aggregates the necessary RW sets and sends them to the ordering service, starting the order phase. Here, through a consensus protocol, a new block is created, defining the total order of transactions, and sent to all peers. In the validate phase, the peers verify the latest transactions and update their world state. This world state is a snapshot of the most recent state of the blockchain.
To improve the data security and compliance with data regulations, Fabric provides data privacy. In this mechanism, data are written in a separated database, are accessible only to the authorized peers, and only the hash of the transaction is saved on the blocks. This allows for personal and sensitive data to be deleted as only the hash is permanently kept. HLF also contains the Membership Service Provider, a service responsible for defining the roles of the entities inside of the network and validating the certificates generated by the Fabric Certificate Authority that is abstracted through this service.
It is through those services that Fabric provides the necessary data privacy and security to the blockchain solution.

A SCALABLE BLOCKCHAIN-BASED SOLUTION FOR REPUTATION MANAGEMENT
The proposed system architecture is composed of two major components: the blockchain, where all of the reputation events are stored, and the cloud infrastructure, which is responsible for reputation management and the app cybersecurity processes. The cloud infrastructure supports an interface that provides the QA and security teams with the necessary dashboards for their analysis, creating an intelligent decision support system.
This cloud is only a complementary module, provided as software as a service, since the blockchain is enough to store the reputation events. However, through the cloud it is possible to deliver a dedicated interface to the QA and security teams to analyze the apps considered dangerous by the reports provided by the users, thus improving the cybersecurity processes of app stores (for example, there is more efficiency in reviewing the apps).
The cloud is responsible for 1) gathering events from the Aptoide app store (in our case), processing them (to create the reputation events), and sending them to the blockchain; 2) collecting the events from the blockchain from all app stores and computing the users' reputations and app threat levels; and 3) orchestrating the two modules and producing the necessary data for the interface, namely what apps have a higher priority in being analyzed, considering the reputations of the users and their feedback.
T he task div ision bet ween t he cloud and blockchain is crucial as it determines not only the efficiency of our solution but also its accessibility to other app stores. The blockchain saves the reputation events-and not the reputation itself-increasing the interoperability, which allows each store to model them following their business model. By proving an external application programming interface (API), this interoperability is improved as it dismisses the complicated knowledge to communicate directly with the blockchain. This API has four operations: 1) insert event: add new reputation events; 2) get event: get a specific event; 3) get by date: fetch all events that were added to the blockchain on a particular day; and 4) get by user: returns all events from a user.
To guarantee that the blockchain is app store agnostic, a reputation event that is as generic as possible was defined, reducing the complexity of the smart contract (that is, the chaincode in our blockchain implementation), making it easier for any app store to send and receive reputation events. These include event_id: the ID of the event, generated by each app store; store_name: the field that contains the app store name; user_ e-mail: the email of the user; user_type: the type of the user (developer or consumer); action: the action performed by the user; value_of_action: the value of the action itself (for example, the flag given); destination_e-mail: who receives the action; added_on: a timestamp from when the event was added to the blockchain [in coordinated universal time (UTC)], added upon insertion in the blockchain; and occurred_ on: a timestamp from when the event occurred in the app store. To differentiate between the different app stores, each app store in the consortium will have a unique ID to place at the beginning of the ID field.
The default HLF Certificate Authority was used to generate X509 certificates. As for the consensus algorithm, we used Raft. This protocol works in a leader-follower fashion, is crash fault tolerant, and can be distributed in different servers and organizations, thus decentralizing the control of the consensus algorithm. Raft is the first fully consensus protocol integrated in Fabric (implemented in V1.4.1, April 2019), therefore providing fast integration and a higher performance when compared to its ancestor, a junction of Kafka and ZooKeeper.
All Fabric components run in containers and communicate through Remote Procedure Calls over a secure and authenticated channel using Transport Layer Security protocol. The chaincode was written in Go, and our endorsement policy stated that at least one peer of each organization (randomly chosen by Fabric) has to endorse the transaction.
The version of the HLF used is 1.4.1. For the implementation and our proof of concept, two organizations were used for deployment, the real app store, Aptoide, and a dummy app store, named app store X, to simulate the dissemination of information in the blockchain.

Cloud implementation
The proposed cloud solution, integrated with the blockchain, serves the purpose of supporting the described intelligent decision support system. It is microservice oriented and built on top of two main modules: Event Tracker and Data Collection ( Figure 1).
The Event Tracker module is responsible for fetching the events from the app store, analyzing each one individually, and rerouting them to the blockchain (Figure 1). If the event is a flag (Aptoide allows users to flag its app), it is stored in a local   cache, waiting for the analysis of the QA reviewer to assess its truthfulness. That review creates a new event (QA review) used to evaluate all flags given to that app to determine their accuracy, propagating that information to the blockchain. This increases the reliability since only truthful events are stored in the blockchain, which later reduces the logic needed in computing the user's reputation. If the event is none of the above, it is adequately treated and sent to the blockchain.
To increase the performance of cybersecurity processes and notif y the QA team of apps that require immediate action, the flags given by high-reputation users and uploads by low-rated developers are also treated separately to update the app threat level and the list of apps submitted by low-rated developers, respectively. This app threat level represents the severity deemed by the system for each app, increasing or decreasing its urgency in being reviewed, making the system react faster to what may be the biggest threats to the end users.
The Data Collection module (Figure 1) is responsible for collecting the events from the blockchain, including from other stores as well. During this phase, the reputation events are processed through an internally defined reputation system, and the reputation of the users involved is updated. If the user is new on Aptoide, we check to see if he has already done other actions on other app stores, updating his reputation accordingly. Then, the system updates the threat level for each app with the updated reputations. Each module is executed once per day by a scheduler, given that the Event Tracker always starts first at the beginning of the day (after midnight in UTC) by fetching the events from the previous day and sending them to the blockchain through the add_event functionality. However, if it is deemed necessary (for example, by an increase in flag actions), it can be executed more frequently, further decreasing the reaction time. The Data Collection module then fetches all of the events from all of the app stores from the previous day using the get_event_by_date functionality. This query is done on the date from which the events were added to the blockchain to avoid missing events added by other app stores that occurred before the previous day but were all added on that last day.

EVALUATION RESULTS
The evaluation consisted of several tests. First, we tested the HLF configuration to benchmark and test the performance, scalability, and fault tolerance. Then, we tested the off-chain solution to evaluate the capacity of the system in managing several thousands of events. All of the tests were performed on a Dell R210-2 remote server with an Intel Quad-Core Xeon E3-1270v2, with 16-GB DDR3 of RAM and 2-TB SATA2 for the hard drive, running Ubuntu 16.04 LTS.

HLF evaluation
Three different steps in the evaluation 18,20 were defined. First, the perfor-mance was evaluated by measuring the impact of changing first the block size and then the number of transactions on each block. Second, the scalability was evaluated by adding more peers to the organizations, and third, the fault tolerance was evaluated. For each test, two metrics are presented, the latency (time of each operation to complete) and throughput (TPS). Moreover, the tests do not include the authentication of users, which is one of the most cumbersome steps as it is processed outside of HLF itself. The experiments were performed by Hyperledger Caliper, a benchmark tool for Hyperledger blockchains.
In this scenario, three functionalities were tested: a write operation (add_event), a read operation (get_by_ id), and a read operation that returns several events (get_by_date). For each event, 1,000 different transactions were sent at a rate of 100/s. The fields in the events were generated randomly (aside from the ID) and incrementally, starting at one, and the date was chosen randomly for a set of 10 different dates. The maximum number of transactions to be sent per second was 100. The initial configuration contained two peers in each organization and three raft nodes. Figure 2 contains the results of the tests, where each plot contains the results for all three operations.
Aside from the block size, we used the initial configuration provided by the HLF. Figure 2(a) and (b) indicates that both the latency and TPS are somewhat stable through the trials, with a small peak in TPS for the add_event operation at 2 MB. This cap is explained by the limitation on the number of transactions. Therefore, we increasingly changed this limitation to observe its behavior. From Fig ure 2(c) and (d), it is observable how incrementing the number of transactions improves the performance. Latency wise, further increases are not observable after 75 transactions per block. As for the TPS, it reaches its peak at 100 transactions per block, with approximately 70 TPS for write operations. It is here that the network reaches its saturation and is not capable of processing more transactions.
The scalability of the system was tested by iteratively adding peers to each organization. The initial configuration is the one with the best results [ Figure 2(e) and (f)]. These results are not expected as having more peers means more availability. However, an observation on the resource consumption explains this performance, as the tests are run in a single server that rapidly reaches its limit, and the Caliper must wait for all of the peers to commit the new block.
Finally, the system was tested regarding its fault tolerance [ Figure 2(g) and (h)]. From the results, it is possible to conclude that adding fault tolerance does not create performance issues. This is expected, as the messages are only sent to the leader, which simultaneously propagates the message and waits for a majority of the responses. Therefore, as long the number of nodes does not consume all of the server resources, it is not expected that we would observe changes in the times reported. For the following tests, the number of raft nodes was set to three.
The configuration found is useful for our setup but may not be the best for others. However, these tests show how versatile and scalable the HLF is, where it is possible to add or remove peers in any location due to its modularity.

Cloud evaluation
Af ter finding the best configuration for HLF, the whole system was tested by generating 10,000 reputation events (a number way above the average daily in Aptoide) for 1,000 users (that were previously inserted in the database), corresponding to a fictional day. Using the flow in Figure 1, the results presented here include preprocessing the data, sending events to the blockchain, requesting those events, and updating the reputations and app threat levels. Note that, despite all of the components being in the same network, the requests are not made in localhost to approximate the results with a real-world scenario without adding too much latency.
Preprocessing the data and sending them to the blockchain is continuous; however, run times are presented separately to facilitate the analysis of each module. The full process for the 10,000 events took approximately 11 h. The initial flow of the cloud takes the most time, having 1 h in preprocessing and almost 10 h in sending them to the blockchain. The processes of preparing and analyzing the data are extremely fast, demonstrating the ability to quickly react to new threats while preparing the events.
Sending the events to the blockchain is where the system spends most of its time, averaging 3 s per event, which includes the latency of the requests, authentication (done for every new request), HLF internal flow, and the response, all of which become the bottleneck of our system. Given the added layer provided by the blockchain, with the extra steps of security and replication and the fact that our implementation is a proof of concept that does not consider parallelization strategies, these times are not a surprise and confirm that the system can be improved to leverage the capabilities of HLF and deliver higher performances.
To request the 10,000 events from the blockchain, it only took 3 s, which is a fast response considering the number of events and the times to send them. Then, it took almost 18 min to process all of those events and update the reputations and app threat levels. This demonstrates how fast the offchain solution can collect the events and process them, reacting rapidly to