Ensuring Resource Trust and Integrity in Web Browsers Using Blockchain Technology

Abstract

Current web technology allows the use of cryptographic primitives as part of server-provided Javascript. This may result in security problems with web-based services. We provide an example for an attack on the WhisperKey service. We present a solution which is based on human code reviewing and on CVE (Common Vulnerabilities and Exposures) data bases. In our approach, existing code audits and known vulnerabilities are tied to the Javascript file by a tamper-proof Blockchain approach and are signaled to the user by a browser extension. The contribution explains our concept and its workflow; it may be extended to all situations with modular, mobile code. Finally, we propose an amendment to the W3C subresource recommendation.

1 Introduction

Despite the popularity and widespread use of Javascript in web-development, client-side execution of cryptography-focused Javascript remains a serious security issue. The user cannot trust the functionality downloaded from the server, since the service provider may incorrectly apply cryptographic primitives, include backdoors or even access private keys stored on the client. The service provider may do so voluntarily for criminal reasons, or involuntarily due to a court order, in forced collaboration with surveillance institutions. Several web-based messenger applications such as ChatCrypt¹ and WhisperKey² still deal with this problem, whereas Cryptocat³ already moved away from in-browser Javascript execution and instead uses a browser plug-in model [10, 27].

Even though many web-applications are available for review on repository websites such as GitHub⁴ or GitLab⁵, they still do not prevent the service provider from serving tampered files to the end-user. To prevent such an attack, each user would have to review the code himself/herself. Even for small scripts, this is only an option for skilled experts. Moreover, reviewing incoming Javascript files each time before execution is cumbersome and not feasible. In addition, this approach works only for small scripts and is not applicable for complex applications. Finally, code obfuscation techniques make this task even more difficult.

We propose to combine blockchain technology and openly accessible code reviews of static code files in order to prevent server-side code poisoning attacks. Developers push their files to an online repository, such as GitHub or GitLab, and make them available to external reviewers. At the same time, the hash of the files is published to a blockchain, for example the Bitcoin blockchain, where it is stored as permanent and tamper-free reference. Code reviewers post their reviews and secure them by including the hash of their review as well as of the reviewed code in the same blockchain. As soon as the browser of the end-user receives the Javascript code, it checks the hash of the received files against the blockchain entry. The code is executed only if the hashes match and no negative reviews indicate a security risk.

This work addresses the identified gap by introducing a concept to detect and prevent server-side code poisoning attacks, thereby answering the question of how to prevent manipulation of static in-browser files using a blockchain-based peer review system. In this contribution we shall describe the general workflow of our proposal, the specifics of the code review process, and finally the mechanisms that ensure the trustworthiness of this process. As we shall explain by a security analysis of the WhisperKey service, the security gap is a real one and endangers existing services.

WhisperKey (see footnote 2) offers secure messaging within the browser. According to their web page and our analysis it works as follows: The recipient loads a particular URL of the portal, which has the browser generate a (public, private) key pair. The private key is stored in unencrypted form in the local storage of the browser, whereas the public key is sent to the WhisperKey server, where it is stored together with further identifiers, so called magic words. The recipient forwards these magic words to the person from which she wants to receive a message. The sender provides the WhisperKey server with the magic words he obtained from the recipient and in turn his browser receives the associated public key. When typing the message, the browser of the sender encrypts the plain text and forwards the cypher text to the WhisperKey server, which again forwards it to the receiver. The receiver is identified by the magic words. Finally the receiver uses her private key to decrypt the message. The complete process is a bit more involved and employs hybrid encryption.

Besides security limitations such as short RSA keys, coincidental collisions of magic words or implementation issues, the most serious security issue is a classical man in the middle attack by the WhisperKey server. In this attack (see Fig. 1), WhisperKey distributes Javascript, which extracts the private key of the user from browser local storage and sends the private key back to WhisperKey.

Fig. 1.

Illustration of a server-side code poisoning attack.

The remainder of this paper is structured as follows: Sect. 2 provides some technical background and describes related work. Section 3 introduces the general workflow of our proposal. Afterwards, Sect. 4 expands on the peer-reviewing process. Finally, Sect. 5 concludes this contribution and provides an outlook on future work.

2 Technical Background and Related Work

In recent years, the blockchain concept majored and spread in popularity. Besides the initial Bitcoin blockchain, several other architectures emerged, e.g., Ethereum⁶, Qtum⁷, or RSK⁸. Moreover, a variety of applications and use-cases for blockchains have been proposed, e.g., as a platform for IoT (Internet of Things) applications [8, 12], in the legal industry [18], in the finance sector [17, 26] or as part of security and authentication protocols [11, 13, 20].

A blockchain consists of a chronologically ordered chain of blocks, where each block consists of a number of validated transactions. Each block links to its predecessor by a hash reference, so that changing the content of one block also changes all succeeding blocks and hence breaks the chain. All blocks are stored on and verified by all participating nodes. The blockchain concept, also referred to as distributed ledger system, is most noticeably known for providing the foundation of the peer-to-peer (P2P) cryptocurrency and payment system Bitcoin [16]. It consists of quite a number of minor additional protocol elements, for example providing a trustworthy time-base and scaling the difficulty of the proof-of-work to the number of participating nodes. The current market capitalization of crypto-currencies serves as pragmatic proof of their security.

In our application, we use the fact that information encoded into a blockchain cannot be tampered with at a later moment. In Bitcoin this can be achieved somewhat artificially using the OP_RETURN script instruction, it is limited to 80 bytes [3] and produces considerable costs in transaction fees. Ethereum offers more flexibility, but still has high fees for some aspects of our use case; [6] describes a possibility to reduce the fees using off-chain storage. IOTA has an even more natural structure with regard to tamper-protecting hashed data [21] and works without per-transaction fees. [19] describes alternative architectures and suggests special-use private chains. Such an infrastructure could be operated by the open source community and protect the delivery of security critical software on the web for the general public, completely without the need for transaction-based fees.

The problem of server-side code poisoning is well known from content distribution networks (CDN), the deployment of which usually requires are careful balancing of trust, performance, and security issues [29]. CDNs do not offer protection against server-side code poisoning but further exemplify the size of the problem. The W3C subresource integrity recommendation [1] provides techniques to ensure that the CDN delivers that code for inclusion of subresources which the author of the main document expects. For example, style-sheets or Javascript libraries may be included by a main document; the including tag in the main document may provide hash-codes for the subresources. This enables the browser to check whether the (CDN-served) subresources are really what the author of the (provider-served) main document expected. However, this approach does not preclude an intentional attack by the service-provider and lacks the connection from the load process to known component vulnerabilities.

3 Concept Overview

The following section provides a general overview on the workflow of our solution. Figure 2 illustrates our approach in general. Its left hand side presents the current state of the art as discussed previously in Sect. 2, whereas the right hand side of the figure presents our proposal that extends the current workflow.

The WhisperKey developer writes the code for WhisperKey and deploys the resulting application on the WhisperKey webserver. The source code is pushed to the developers public code repository, on GitLab or GitHub. The user accesses the WhisperKey application using a suitable device and executes the Javascript code provided by the webserver. Thus far, the user is still prone to server-side code poising or other vulnerabilities that might be caused by the Javascript file.

Fig. 2.

General overview of the protocol workflow.

In order to prevent this attack, we propose an expert-driven, decentralized peer-review process. As illustrated in Fig. 2, a reviewer that is interested in analyzing the WhisperKey application pulls a copy of the latest source code from the corresponding public code repository. The results of the code analysis are stored in an audit report. This report either states that the reviewer is confident that the code is secure and recommended for daily use, or it describes the identified security issues.

In order to be eligible to publish code reviews, the reviewer has to provide a financial stake in form of a pre-defined cryptocurrency, such as Bitcoin, Ether, Litecoin or others. The stake is locked up for a defined time period. In case the review turns out to be wrong, the stake is lost. A detailed description of the full peer review process as well as the incentive system for participating reviewers is provided in Sects. 4.1 and 4.3. After the review, the git hash of the reviewed code version, as well as the reviewer’s stake and the final review report (or the value of a cryptographic hash function on this report) are posted to the blockchain ($block_{x-2}$). Our solution does not require a specific blockchain architecture, as long as it is possible to store string encoded information as part of a transaction.

In order to enable users of the WhisperKey application to utilize the reviews available on the blockchain, we propose a web browser extension that interacts with the corresponding blockchain. Figure 3 provides a BPMN [4] illustrations of a local user’s client requesting and processing an incoming file that has been reviewed by a reviewer. For this purpose, the user interacts with a small number of full blockchain nodes; the user does not have to run a full blockchain node herself but relies on a majority vote of a small number of those nodes. The browser extension regularly queries these full nodes for updates on reviews (e.g. $block_{x}$) and stores a list of files with their latest review results on the local user device. In case an incoming file from the WhisperKey website is marked as insecure, the browser prevents the execution of the file and outputs a warning to the user; if no information or positive reviews are found, the extension signals this appropriately. The rewards for the reviewers depend on the popularity of the reviewed file – the more clients report queries for a specific file, the higher the reward for the reviewer. Details of the incentive mechanism are discussed in Sect. 4.3.

Fig. 3.

BPMN representation of the local client requesting and processing an incoming file.

Finally, we need a mechanism to prove code vulnerability in order to invalidate existing positive reviews. Despite human-based conflict resolution mechanisms as discussed later in Sect. 4.3, an indisputable source of discovered vulnerabilities is the CVE system⁹. The CVE system lists publicly known cybersecurity vulnerabilities with a unique identification number, a description as well as at least one public reference for each vulnerability. In case a new CVE entry for a previously reviewed file is listed, the CVE-ID with a reference ID for the affected review is posted to the blockchain ($block_{x-1}$) resulting in a lost stake for the reviewer as well as a new negative review for the concerned file.

4 Peer-Reviewing Process

A peer-review based analysis of the provided resource, e.g., a Javascript file, is one of the main components of our proposal. Especially in software development and academic research, the process of transparent peer-reviewing is a common practice for quality assurance, e.g., [2, 22,23,24,25]. We illustrate the peer-review process in Sect. 4.1, the conflict resolution mechanism in Sect. 4.2 as well as the incentive mechanisms for all involved entities in Sect. 4.3.

4.1 Peer-Reviewing

As briefly outlined in Sect. 3, a reviewer that is interested in reviewing a specific resource, for example a Javascript file hosted on GitHub, pulls the version that he/she is interested in reviewing. Afterwards, the reviewer performs a detailed and thorough analysis of the code and compiles a review report. Among others, the report contains the following information: Project name, project description, link to resource repository, hash of the committed version that has been reviewed, the resource itself, information about the reviewer as well as a detailed description of the review results. Finally, the report also contains a boolean value that indicates whether the reviewer suggests that the resource is secure and recommended for daily use or not - true in case the resource is secure and otherwise false. The inclusion of these meta-data as part of the report makes it available to the browser extension and to further automated processing and decision algorithms.

After completing the review process, the reviewer posts a short version or a hash of the report to a specified blockchain; the detailed report is stored in a decentralized and distributed file system (such as IPFS¹⁰ [9]) as a reference. The short version contains the git commit hash, the project name, the resource hash and the boolean value indicating a secure or insecure file. When posting the review report to the chain, the reviewer also makes a deposit that is locked up as a stake for a predefined time period. In case the submitted review turns out to be wrong, the reviewer loses the stake. Further reviewers might add additional reviews for of the same resource thereby providing a peer-based security evaluation.

4.2 Conflict Resolution

Assuming that a certain resource receives multiple reviews, we may end up in a situation where either all reviewers agree or in a scenario with divergent results. Given the case that we have two reviews declaring a resource as secure and two other reviews claiming the exact opposite, we have to decide how to treat the resource when a browser queries the reviews for this file. Is it secure or not? A conservative approach is to tag all files as insecure that received a single negative review. The downside of this solution is a potential denial of service scenario where an attacker posts a negative review to undermine the trustworthiness of a competitor. Hence, an independent and trusted conflict resolution mechanism is required.

As described in Sect. 3, CVEs are a potential solution for the issue described above. A software that is referenced in the CVE system as vulnerable can be marked as insecure. Hence, a resource version that corresponds to an entry in the CVE system is by default not secure and the reviewers that posted a positive review lose their stakes. The problem with the CVE system is, that it does not list all existing vulnerabilities for each application or software produce, for example, a Cross-Site-Scripting (XSS) vulnerability on a private website. Thus an alternative solution is required.

Semada¹¹ is a decentralized and autonomous platform that enables a reputation-driven meritocracy with a domain expert focused reputation system [5]. Experts with knowledge in a specific domain can sign up and provide proofs-of-expertise for the domain. Experts act as validators who make stakes to answer validation requests, e.g., questions targeting a specific field of expertise. The experts bet their stakes in a betting pool depending on their point-of-view on a specific issue and a majority vote decides the answer to the validation request. A Semada-like platform with software security experts might be an alternative conflict resolution platform to decide on the (in)security of a reviewed resource.

4.3 Incentive Mechanism

Finally, we introduce an incentive mechanism for our proposed concept. First, the incentive for the user that runs a client on his device in order to avoid executing insecure code, the incentive for using the system is quite simple - enhanced security. Similar applies to the developer of the used application: Code reviews of external reviewers significantly increase the security of software code [7, 14, 15].

The incentive for the reviewers is manifold. First, we propose a Steemit-like¹² incentive system for reviews. The Steem network continually creates new tokens that reward content creators and curators of the platform [28]. Similarly, we propose to incentivize reviewers by rewarding tokens based on the popularity of reviewed code, e.g., one million user clients queried the review for a specific file results in a certain amount of reward tokens. The reward is locked up together with the reviewers stake for some time and released over time. In case a vulnerability is found, the stake as well as the reward tokens are lost. In order to avoid millions of reviews for popular files and no reviews for less popular resources, the reward tokens are split among all reviewers. In addition, we propose to incentivize the first reviewers of a specific resource be awarding new minted tokens to them, thereby increasing the incentive to providing at least a few reviews to less popular files. Furthermore, interested users can also offer bounties for unreviewed files that would like to see reviewed, resulting in a further incentive.

Stakes and rewards that are lost due to a discovered vulnerability in a positively reviewed file might be burned, send to a non-profit organization such as the Linux foundation¹³ or MOSS¹⁴, or are awarded to the reviewer that discovered the vulnerability.

5 Conclusion and Future Work

We have provided concepts how blockchain technology can make the distribution of mobile code more secure. First, tampering with the reviewed status of Javascript code is prevented when the downloaded code is bound to a hash-value which is encoded into the blockchain. The browser can check that it is in fact receiving the same code base as it is held available in a public repository, such as GitHub or GitLab, which is mentioned in the metadata of a review. Second, code quality reviews may be bound to the hash of the file and ensure that the application has been analyzed by a person who has a stake in the correct functioning of that particular code. Finally, we believe that our concept is useful for and can be adapted to every situation where software or documents are downloaded from various different locations.

As short-term future work we plan to transform our contribution from the level of a conceptual workflow scheme (as in Fig. 2) into a semi-formally specified REST-Api and to provide experimental implementations on top of the Ethereum blockchain and the IOTA tangle system. On the client side, we intend an implementation in the form of a browser extension, which interacts with blockchain nodes. Moreover, we believe that web browser security in general would benefit from a standardized interface through which trusted subresources of a page can be loaded and connected to open repositories as well as review and reputation sites. The subresource integrity recommendation of the W3C [1] already realizes most of this but need to be amended by a mechanism connecting subresources to reviews and validation mechanisms.

Moreover, we identify the following long-term research questions for the blockchain community in general. Current consensus technology seems to work well when it boils down to checking facts which may be verified algorithmically, such as checking whether a Bitcoin transaction has been signed by a private key belonging to a public key whose hash equals the address, or ensuring that a certain event had been raised by an authenticated party to a smart contract. In our use case we can ensure that a reviewer had written a positive review for a file with a specific content and that the review subsequently was invalidated by an entry into a CVE data base. However, we still have a trust gap between intended and realized human behavior. How do we ensure that a reviewer invests sufficient time to produce a good review or generates a reasonable CVE entry? In Bitcoin the incentive structure is much simpler, but while it provides sufficient motivation to miners for generating blocks, its translation to traditional economics is far from clear as can be recognized from the high volatility of the Bitcoin course as well as from an unending stream of warnings, comparisons with the tulip bubble, and claims that it is a ponzi scheme.

Finally, future developments might focus on creating a distributed autonomous organization (DAO) that enables the resource review system. Users participating in the DAO build their reputation in the same way as described in this work, but in addition they follow a common review protocol as well as best practices that are contentiously enhanced by the DAO’s members. Disputes are resolved in a Semada-like manner using a validation betting pool.