Countering Trusting Trust through Diverse Double-Compiling

An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some compiler defects as well. Simply recompile the source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.Comment: 13 pages

Atomic Information Disclosure of Off-Chained Computations Using Threshold Encryption

Public Blockchains on their own are, by definition, incapable of keeping data private and disclosing it at a later time. Control over the eventual disclosure of private data must be maintained outside a Blockchain by withholding and later publishing encryption keys, for example. We propose the Atomic Information Disclosure (AID) pattern based on threshold encryption that allows a set of key holders to govern the release of data without having access to it. We motivate this pattern with problems that require independently reproduced solutions. By keeping submissions private until a deadline expires, participants are unable to plagiarise and must therefore generate their own solutions which can then be aggregated and analysed to determine a final answer. We outline the importance of a game-theoretically sound incentive scheme, possible attacks, and other future work

The Challenge and Promise of Using Community Policing Strategies to Prevent Violent Extremism: A Call for Community Partnerships with Law Enforcement to Enhance Public Safety

More than four years ago, the White House issued a national strategy calling for the development of partnerships between police and communities to counter violent extremism. This report contains the results of a comprehensive assessment of the challenges and promise of this strategic approach to preventing violent extremism. It is based on a nationwide survey of law enforcement agencies and hundreds of hours of interviews and site visits with police departments and community members around the country. Based on this research, we reached two fundamental conclusions. First, policing agencies face multiple obstacles to creating community partnerships focused on preventing acts of violent extremism. But, second, some policing agencies are following a set of promising practices which, if applied effectively, can result in increasing trust between the police and the communities they serve. These trusting relationships can serve as a platform for addressing many public safety threats, including, but not limited to, violent extremism

Taxonomy of Attacks on Open-Source Software Supply Chains

The widespread dependency on open-source software makes it a fruitful target for malicious actors, as demonstrated by recurring attacks. The complexity of today's open-source supply chains results in a significant attack surface, giving attackers numerous opportunities to reach the goal of injecting malicious code into open-source artifacts that is then downloaded and executed by victims. This work proposes a general taxonomy for attacks on open-source supply chains, independent of specific programming languages or ecosystems, and covering all supply chain stages from code contributions to package distribution. Taking the form of an attack tree, it covers 107 unique vectors, linked to 94 real-world incidents, and mapped to 33 mitigating safeguards. User surveys conducted with 17 domain experts and 134 software developers positively validated the correctness, comprehensiveness and comprehensibility of the taxonomy, as well as its suitability for various use-cases. Survey participants also assessed the utility and costs of the identified safeguards, and whether they are used

It’s like flossing your teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security

The 2020 Solarwinds attack was a tipping point that caused a heightened awareness about the security of the software supply chain and in particular the large amount of trust placed in build systems. Reproducible Builds (R-Bs) provide a strong foundation to build defenses for arbitrary attacks against build systems by ensuring that given the same source code, build environment, and build instructions, bitwise-identical artifacts are created. Unfortunately, much of the software industry believes R-Bs are too far out of reach for most projects. The goal of this paper is to help identify a path for R-Bs to become a commonplace property. To this end, we conducted a series of 24 semi-structured expert interviews with participants from the Reproducible-Builds.org project, and iterated on our questions with the reproducible builds community. We identified a range of motivations that can encourage open source developers to strive for R-Bs, including indicators of quality, security benefits, and more efficient caching of artifacts. We identify experiences that help and hinder adoption, which heavily include communication with upstream projects. We conclude with recommendations on how to better integrate R-Bs with the efforts of the open source and free software community

Attributes and Dimensions of Trust in Secure Systems

What is it to be trusted? This is an important question as trust is increasingly placed in a system and the degree to which a system is trusted is increasingly being assessed. However, there are issues with how related terms are used. Many definitions focus on one attribute of trust (typically behaviour) preventing that definition from being used for other attributes (e.g., identity). This is confused further by conflating what trustors measure about a trustee and what conclusions a trustor reaches about a trustee. Therefore, in this paper we present definitions of measures (trustiness and trustworthiness) and conclusions (trusted and trustworthy). These definitions are general and do not refer to a specific attribute allowing them to be used with arbitrary attributes which are being assessed (e.g., identity, behaviour, limitation, execution, correctness, data, environment). In addition, in order to demonstrate the complexities of describing if a trustee is designated as trusted or trustworthy, a set of dimensions are defined to describe attributes (time, scale, proactive/reactive, strength, scope, source). Finally, an example system is classified using these attributes and their dimensions in order to highlight the complexities of describing a system as holistically trusted or trustworthy