Trust in Computer Systems and the Cloud

Mike Bursell

• Publisher: Wiley
• Year: 2021
• Print ISBN: 9781119692324
• eBook ISBN: 9781119692317
• Edition: 1
• Topic: Computer Science
• Subtopic: Cryptography
• Index: Computer Science

Learn to analyze and measure risk by exploring the nature of trust and its application to cybersecurity Trust in Computer Systemsand the Cloud delivers an insightful and practical new take on what it means to trust in the context of computer and network security and the impact on the emerging field of Confidential Computing. Author MikeBursell'sexperience, ranging from Chief Security Architect at Red Hat to CEO at a Confidential Computing start-up grounds the reader in fundamental concepts of trust and related ideas before discussing the more sophisticated applications of these concepts to various areas in computing.

The bookdemonstratesin the importance of understanding and quantifying risk and draws on the social and computer sciences to explain hardware and software security, complex systems, and open source communities. It takes a detailed look at the impact of Confidential Computing on security, trust and risk and also describes the emerging concept of trust domains, which provide an alternative to standard layered security.

• Foundational definitions of trust from sociology and other social sciences, how they evolved, and what modern concepts of trust mean to computer professionals
• A comprehensive examination of the importance of systems, from open-source communities to HSMs, TPMs, and Confidential Computing with TEEs.
• A thorough exploration of trust domains, includingexplorationsof communities of practice, the centralization of control and policies, and monitoring

Perfect for security architects at the CISSP level or higher, Trust in Computer Systemsand the Cloud is also an indispensable addition to the libraries of system architects, security system engineers, and master's students in software architecture and security.

CHAPTER 1
Why Trust?

I trust my brother and my sister with my life. My brother is a doctor, and my sister trained as a diving instructor, so I wouldn't necessarily trust my sister to provide emergency medical aid or my brother to service my scuba gear. I should actually be even more explicit because there are times when I would trust my sister in the context of emergency medical aid: I'm sure she'd be more than capable of performing CPR, for example. On the other hand, my brother is a paediatrician, not a surgeon, so I'd not be very confident about allowing him to perform an appendectomy on me. To go further, my sister has not worked as a diving instructor for several years now, so I might consider whether my trust in her abilities should be impacted by that.

This is not a book about human relationships or trust between humans, but about trust in computer systems. In order to understand what that means—or even can mean—however, we need to understand what we mean by trust. Trust is a word that arises out of human interactions and human relationships. Words are tricky. Words can mean different things to different people in different contexts.

The classic example of words meaning different things depending on context is the names of colours—the light frequencies included in the colours I identify as mauve, beige, and ultramarine are very likely different to yours—but there are other examples that are equally or more extreme. If I discuss “scheduling” with an events coordinator, a DevOps expert, and a kernel developer, each person will almost certainly have a different view of what I mean.

Trust is central to the enterprise of this book, and to discuss it, we must come to some shared understanding of what is meant by the word itself.¹ The meaning that we carry forward into our discussion of computer systems must be, as far as is possible, shared. We must, to the extent we can, come to agree on a common referent, impossible as this exercise may seem in a post-modern world.² Our final destination is firmly within the domain of computing, where domain-specific vocabulary is well-established. But since day-to-day usage of the word trust is rooted in a discussion about relationships between humans, this is where we will start.

The sort of decisions that I have described around trusting my sister and brother are ones that humans make all the time, often without thinking about them. Without giving it undue thought, we understand that multiple contexts are being considered here, including:

• My relationship to the other person
• Their relationship to me
• The different contexts of their expertise
• The impact that time can have on trust

This list, simple as it is, already exposes several important points about trust relationships to which we will return time and time again in this book: they are asymmetric (trust may be different in one direction to another), they are contextual (medical expertise and diving equipment expertise are not the same), and they are affected by time. As noted earlier, this book is not about human relationships and trust—though how we consider our relationships will be important to our discussions—but about trust in computing systems. Too often, we do not think much about trust relationships between computing systems (hardware, software, and firmware), and when we do, the sort of statements that tend to emerge are “This component trusts the server” or “We connect to this trusted system”. Of course, in the absence of significantly greater levels of artificial intelligence than are currently in evidence at the time of writing, computing systems cannot make the sort of complex and nuanced decisions about trust relationships that humans make; but it turns out that trust is vitally important in computing systems, unstated and implicit though it usually is.

There is little discussion about trust—that is, computer-to-computer or machine-to-machine trust—within the discipline or professional practice of computing, and very little literature about it except in small, specialised fields. The discussions that exist tend to be academic, and there is little to find in the popular professional literature—again, with the exception of particular specialised fields. When the subject of trust comes up in a professional IT or computing setting, however, people are often very interested in discussing it. The problem is that when you use the word trust, people think they know what you mean. It turns out that they almost never do. What one person's view of trust entails is almost always different—sometimes radically different—from that of those to whom they are speaking. Within computing, we are used to talking about things and having a shared knowledge, at least to some degree of approximation. Some terms are fairly well defined in the industry, at least in general conversation: for example, cryptography, virtualisation, and kernel. Even a discussion on more nebulous concepts such as software or networking or authentication generally starts from a relatively well-defined shared understanding. The same is not true of trust, but trust is a concept that we definitely need to get our heads around to establish a core underpinning and begin to frame an understanding of what shared meaning we hope to convey.

Why is there such a range of views around trust? We have already looked at some of the complexity of trust between humans. Let us try to tease out some of the reasons for people's confusion by starting with four fairly innocuously simple-looking statements:

• I trust my brother and my sister.
• I trust my bank.
• My bank trusts its IT systems.
• My bank's IT systems trust each other.

When you make four statements like this, it quickly becomes clear that something different is going on in each case. Specifically, the word trust signifies something very different in each of the four statements. Our first step is to make the decision to avoid using the word trust as a transitive verb—a word with a simple object, as in these examples—and instead talk about trust relationships to another entity. This is because there is a danger, when using the word trust transitively, that we may confuse a unidirectional relationship with a bidirectional relationship. In the second case, for example, the bank may well have a relationship with me, but it is how I think of the bank, and therefore how I interact with it, which is the relationship that we want to examine. This is not to say that the relationship the bank has with me is irrelevant to the one I have with it—it may well inform my relationship—but that the bank's relationship with me is not the focus. For the same reason, we will generally talk about the “trust relationship to” another entity, rather than the “trust relationship with” another, to avoid implying a bidirectional relationship. The standard word used to describe the entity doing the trusting is trustor, and the entity being trusted is the trustee—though we should not confuse this word with other uses (such as the word trustee as used in the context of prisons or charity boards).

Analysing Our Trust Statements

The four cases of trust relationships that we have noted may look similar, but there are important differences that will shed light on some important concepts to which we will return throughout the book and that will help us define exactly what our subject matter is.

• Case 1: My Trusting My Brother and Sister As we have already discussed, this statement is about trust between individual humans—specifically, my trust relationship to my brother, and my trust relationship to my sister. There are two humans involved in each case (both me and whichever sibling we are considering), with all of the complexity that this entails. But we share a set of assumptions about how we react, and we each have tens of thousands of years of genetics plus societal and community expectations to work out how these relationships should work.
• Case 2: My Trusting My Bank Our second statement is about trust between an individual and an organisation: specifically, my trust relationship to a legal entity with particular services and structure. The basis of the expression of this relationship has changed over the years in many places: the relationship I would have had in the UK with my bank 50 years ago, say, would often have been modelled mainly on the relationship I had with one or more individuals employed by the bank, typically a manager or deputy manager of a particular branch. My trust relationship to the bank now is more likely to be swayed by my views on its perceived security practices and its exercising of fiscal and ethical responsibilities than my views of the manager of my local branch—if I have even met them. There is, however, still a human element associated with my relationship, at least in my experience: I know that I can walk into a branch, or make a call on the phone, and speak to a human.³
• Case 3: The Bank Trusting Its IT Systems Our third statement is about an organisation trusting its IT systems. When we follow our new resolution to rephrase this as “The bank having a trust relationship to its IT systems”, it suddenly feels like we have mo...

Table of contents

• Cover
• Table of Contents
• Praise for Trust in Computer Systems and the Cloud
• Trust in Computer Systems and the Cloud
• Introduction
• CHAPTER 1: Why Trust?
• CHAPTER 2: Humans and Trust
• CHAPTER 3: Trust Operations and Alternatives
• CHAPTER 4: Defining Trust in Computing
• CHAPTER 5: The Importance of Systems
• CHAPTER 6: Blockchain and Trust
• CHAPTER 7: The Importance of Time
• CHAPTER 8: Systems and Trust
• CHAPTER 9: Open Source and Trust
• CHAPTER 10: Trust, the Cloud, and the Edge
• CHAPTER 11: Hardware, Trust, and Confidential Computing
• CHAPTER 12: Trust Domains
• CHAPTER 13: A World of Explicit Trust
• References
• Index
• Copyright
• Dedication
• About the Author
• About the Technical Editor
• Acknowledgements
• End User License Agreement