Mike Bursell

Merry Christmas and a Happy New Year!

No post this week: merry seasonal greetings to all who celebrate anything at this time of year.

7 tips for kicking off an open source project

It’s not really about project mechanics at all

I’m currently involved – heavily involved – in Enarx, an open source (of course!) project to allow you run sensitive workloads on untrusted hosts. I’ve had involvement in various open source projects over the years, but this is the first for which I’m one of the founders. We’re at the stage now where we’ve got a fair amount of code, quite a lot of documentation, a logo and (important!) stickers. The project should hopefully be included in a Linux Foundation group – the Confidential Computing Consortium – so things are going very well indeed. We’re at the stage where I thought it might be useful to reflect on some of the things we did to get things going. To be clear, Enarx is a particular type of project: one that we believe has commercial and enterprise applications. It’s also not mature yet, and we’ll have hurdles and challenges along the way. What’s more, the route we’ve taken won’t be right for all projects, but hopefully there’s enough here to give a few pointers to other projects, or people considering starting one up.

The first thing I’d say is that there’s lots of help to be had out there. I’d start with Opensource.com, where you’ll find lots of guidance. I’d then follow up by saying that however much of it you follow, you’ll still get things wrong. Anyway, here’s my list of things to consider.

1. Aim for critical mass

I’m very lucky to work at the amazing Red Hat, where everything we do is open source, and where we take open source and community very seriously. I’ve heard it called a “critical mass” company: in order to get something taken seriously, you need to get enough people interested in it that it’s difficult to ignore. The two co-founders – Nathaniel McCallum and I – are both very enthusiastic about the project, and have spent a lot of time gaining sponsors within the organisation (you know who you are, and we thank you – we also know we haven’t done a good enough job with you on all occasions!), and “selling” it to engineers to get them interested enough that it was difficult to stop. Some projects just bobble along with one or two contributors, but if you want to attract people and attention, getting a good set of people together who can get momentum going is a must.

2. Create a demo

If you want to get people involved, then a demo is great. It doesn’t necessarily need to be polished, but it does need to show that what you’re doing it possible, and that you know what you’re doing. For early demos, you may be talking to command line output: that’s fine, if what you’re providing isn’t a UI product. Being able to talk to what you’re doing, and convey both your passion and the importance of the project, is a great boon. People like to be able to see or experience something, and it’s much easier to communicate your enthusiasm if they have something that’s real which expresses that.

3. Choose a licence

Once you have code, and it’s open source, you want other people to be able to contribute. This may seem like an unimportant step, but selecting an appropriate open source licence[1] will allow other people to contribute on well-understood and defined terms, making it easier for them, and easier for the organisations for which they work to allow them to be involved.

4. Get documentation

You might think that developer documentation is the most important to get out there – otherwise, how will other people get involved and coding? I’d disagree, at least to start with. For a small project, you can probably scale to a few more people just by explaining what the code does, what it should do, and what’s missing. However, if there’s no documentation available to explain what it’s for, and how it’s going to help people, then why would anyone bother even looking at it? This doesn’t need to be polished marketing copy, and it doesn’t need to be serious, but it does need to convey to people why they should care. It’s also going to help you with the first point I mentioned, attaining critical mass, as being able to point to documentation, use cases and the rest will help convince people that you’ve thought through the point of your project. We’ve used a github wiki as our main documentation hub, and we try to update that with new information as we generate it. This is an area, to be clear, where we could do better. But at least we know that.

5. Be visible

People aren’t going to find out about you unless you’re visible. We were incredibly lucky in that just as we were beginning to get to a level of critical mass, the Confidential Computing Consortium was formed, and we immediately had a platform to increase our exposure. We have Twitter account, I publish articles on my blog and at Opensource.com, we’ve been lucky enough to have the chance to publish on Red Hat’s now + Next blog, I’ve done interviews the the press and we speak at conferences wherever and whenever we can. We’re very lucky to have these opportunities, and it’s clear that not all these approaches are appropriate for all projects, but make use of what you can: the more people that know about you, the more people can contribute.

6. Be welcoming

Let’s assume that people have found out about you: what next? Well, they’re hopefully going to want to get involved. If they don’t feel welcome, then any involvement they have will taper off soon. Yes, you need documentation (and, after a while, technical documentation, no matter what I said above), but you need ways for them to talk to you, and for them to feel that they are valued. We have Gitter channels (https://gitter.im/enarx/), and our daily stand-ups are open to anyone who wants to join. Recently, someone opened an issue on our issues database, and during the conversation on that thread, it transpired that our daily stand-up time doesn’t work for them given their timezone, so we’re going to ensure that at least one a week does, and we’ve assured that we’ll accommodate them.

7. Work with people you like

I really, really enjoy meeting and working with the members of Enarx project team. We get on well, we joke, we laugh and we share a common aim: to make Enarx successful. I’m a firm believer in doing things you enjoy, where possible. Particularly for the early stages of a project, you need people who are enthusiastic and enjoy working closely together – even if they’re separated by thousands of kilometres[2] geographically. If they don’t get on, there’s a decent chance that your and their enthusiasm for the project will falter, that the momentum will be lost, and that the project will end up failing. You won’t always get the chance to choose those with whom you work, but if you can, then choose people you like and get on with.

Conclusion – “people”

I didn’t realise it when I started writing this article, but it’s not really about project mechanics at all: it’s about people. If you read back, you’ll find the importance of people visible in every tip, even including the one about choosing a licence. Open source projects aren’t really about code: they’re about people, how they share, how they work together, and how they interact.

I’m certain that your experience of open source projects will vary, and I’d be very surprised if everyone agrees about the top seven things you should do for project success. Arguably, Enarx isn’t a success yet, and I shouldn’t be giving advice at this stage of our maturity. But when I think back to all of the open source projects that I can think of which are successful, people feature strongly, and I don’t think that’s a surprise at all.

1 – or “license”, if you’re from the US.

2 – or, in fact, miles.

Timely risk or risky times?

Being aware of “the long game”.

On Friday, 29th November 2019, Jack Merritt and Saskia Jones were killed in a terrorist attack. A number of members of the public (some with with improvised weapons) and of the emergency services acted with great heroism. I wanted to mention the mention the names of the victims and to praise those involved in stopping him before mentioning the name of the attacker: Usman Khan. The victims, the attacker were taking part in an offender rehabilitation conference to help offenders released from prison to reintegrate into society: Khan had been convicted to 16 years in prison for terrorist offences.

There’s an important formula that everyone involved in risk – and given that IT security is all about mitigating risk, that’s anyone involved in security – should know. It’s usually expressed thus:

Risk = likelihood x impact

Sometimes likelihood is sometimes expressed as “probability”, impact as “consequence” or “loss”, and I’ve seen some other variants as well, but the version above is generally sufficient for most purposes.

Using the formula

How should you use the formula? Well, it’s most useful for comparing risks and deciding how to mitigate them. Humans are terrible at calculating risk, and any tools that help them[1] is good. In order to use this formula correctly, you want to compare risks over the same time period. You could say that almost any eventuality may come to pass over the lifetime of the universe, but comparing the risk of losing broadband access to the risk of your lead developer quitting for another company between the Big Bang and the eventual heat death of the universe is probably not going to give you much actionable information.

Let’s look at the two variables that we need to have in order to calculate risk. We’ll start with the impact, because I want to devote most of this article to the other part: likelihood.

Impact is what the damage will be if the risk happens. In a business context, you want to look at the risk of your order system being brought down for a week by malicious attackers. You might calculate that you would lose £15,000 in orders. On top of that, there might be a loss of reputation which you might calculate at £30,000. Fixing the problem might add £10,000. Add these together, and the impact is £55,000.

What’s the likelihood? Well, remember that we need to consider a particular time period. What you choose will depend on what you’re interested in, but a classic use is for budgeting, and so the length of time considered is often a year. “What is the likelihood of my order system being brought down for a week by malicious attackers over the next twelve months?” is the question you want to ask. If you decide that it’s 0.005 (or 0.5%), then your risk is calculated thus:

Risk = 0.005 x 55,000

Risk = 275

The units don’t really matter, because what you want to do is compare risks. If the risk of your order system being brought down through hardware failure is higher (say 500), then you should probably balance the amount of resources you assign to mitigate these risks accordingly.

Time, reputation, trust and risk

What I’m interested in is a set of rather more complicated risks, however: those associated with human behaviour. I’m very interested in trust, and one of the interesting things about trust is how we decide to trust people. One way is by their reputation: if someone keeps behaving well over a long period, then we tend to trust them more – or if badly, then to trust them less[2]. If we trust someone more, our calculation of risk is likely to be strongly based on that trust, as our view of the likelihood of a behaviour at odds with the reputation that person holds will be informed by that.

This makes sense: in the absence of perfect information about humans, their motivations and intentions, our view of risk must be based on something, and reputation is actually a fairly good measure for that. We might say that the likelihood of a customer defaulting on payment terms reduces year by year as we start to think of them as a “trusted customer”. As the likelihood reduces, we may decide to increase the amount we lend to them – and thereby the impact of defaulting – to keep the risk about the same, year on year.

The risk here is what is sometimes called “playing the long game”. Humans sometimes manipulate their reputation, or build up a reputation, in order to perform an action once they have gained trust. Online sellers my make lots of “good” sales in order to get a 5 star rating over time, only to wait and then make a set of “bad” sales, where they don’t ship goods at all, and then just pocket the money. Or, they may make many small sales in order to build up a good reputation, and then use that reputation to make one big sale which they have no intention of fulfilling. Online selling sites are wise to some of these tricks, and have algorithms to try to protect buyers (in fact, the same behaviour can be used by sellers in some cases), but these are not perfect.

I’d like to come back to the London Bridge attack. In this case, it seems likely that the attacker bided his time over many years, behaving well, and raising his “reputation” among those who knew him – the prison staff, parole board, rehabilitation conference organisers, etc. – so that he had the opportunity to perform one major action at odds with that reputation. The heroism of those around him stopped him being as successful as he may have hoped, but still at the cost of two innocent lives and several serious injuries.

There is no easy way to deal with such issues. We need reputation, and we need to allow people to show that they have changed and can be integrated into society, but when we make risk calculations based on reputation in any sphere, we should take care to consider whether actors are playing a long game, and what the possible ramifications would be if they were to act at odds with that reputation.

I noted above that humans are bad at calculating risk, and to follow our example of the non-defaulting customer, one mistake might be to increase the credit we give to that customer beyond the balance of the increase of reputation: actually accepting higher risk than we would have done previously, because we consider them trustworthy. If we do this, we’ve ceased to use the risk formula, and have started to act irrationally. Don’t do that.

1 – OK, then: “us”.

2 – I’m writing this in the lead up to a UK General Election, and it occurs to me that we actually don’t apply this to most of our politicians.

Confidential computing – the new HTTPS?

Security by default hasn’t arrived yet.

Over the past few years, it’s become difficult to find a website which is just “http://…”. This is because the industry has finally realised that security on the web is “a thing”, and also because it has become easy for both servers and clients to set up and use HTTPS connections. A similar shift may be on its way in computing across cloud, edge, IoT, blockchain, AI/ML and beyond. We’ve know for a long time that we should encrypt data at rest (in storage) and in transit (on the network), but encrypting it in use (while processing) has been difficult and expensive. Confidential computing – providing this type of protection for data and algorithms in use, using hardware capabilities such as Trusted Execution Environments (TEEs) – protects data on hosted system or vulnerable environments.

I’ve written several times about TEEs and, of course, the Enarx project of which I’m a co-founder with Nathaniel McCallum (see Enarx for everyone (a quest) and Enarx goes multi-platform for examples). Enarx uses TEEs, and provides a platform- and language-independent deployment platform to allow you safely to deploy sensitive applications or components (such as micro-services) onto hosts that you don’t trust. Enarx is, of course, completely open source (we’re using the Apache 2.0 licence, for those with an interest). Being able to run workloads on hosts that you don’t trust is the promise of confidential computing, which extends normal practice for sensitive data at rest and in transit to data in use:

storage: you encrypt your data at rest because you don’t fully trust the underlying storage infrastructure;
networking: you encrypt your data in transit because you don’t fully trust the underlying network infrastructure;
compute: you encrypt your data in use because you don’t fully trust the underlying compute infrastructure.

I’ve got a lot to say about trust, and the word “fully” in the statements above is important (I actually added it on re-reading what I’d written). In each case, you have to trust the underlying infrastructure to some degree, whether it’s to deliver your packets or store your blocks, for instance. In the case of the compute infrastructure, you’re going to have to trust the CPU and associate firmware, just because you can’t really do computing without trusting them (there are techniques such as homomorphic encryption which are beginning to offer some opportunities here, but they’re limited, and the technology still immature).

Questions sometimes come up about whether you should fully trust CPUs, given some of the security problems that have been found with them and also whether they are fully secure against physical attacks on the host in which they reside.

The answer to both questions is “no”, but this is the best technology we currently have available at scale and at a price point to make it generally deployable. To address the second question, nobody is pretending that this (or any other technology) is fully secure: what we need to do is consider our threat model and decide whether TEEs (in this case) provide sufficient security for our specific requirements. In terms of the first question, the model that Enarx adopts is to allow decisions to be made at deployment time as to whether you trust a particular set of CPU. So, for example, of vendor Q’s generation R chips are found to contain a vulnerability, it will be easy to say “refuse to deploy my workloads to R-type CPUs from Q, but continue to deploy to S-type, T-type and U-type chips from Q and any CPUs from vendors P, M and N.”

hardware availability: it is only over the past 6-12 months that hardware supporting TEEs has started to become widely available, with the key examples in the market at the moment being Intel’s SGX and AMD’s SEV. We can expect to see other examples of TEE-enable hardware coming out in the fairly near future.
industry readiness: just as cloud use is increasingly becoming accepted as a model for application deployment, regulators and legislators are increasing the requirements on organisations to protect the data they manage. Organisations are beginning to clamour for ways to run sensitive applications (or applications that handle sensitive data) on untrusted hosts – or, to be more accurate, on hosts that they cannot fully trust with that sensitive data. This should be no surprise: the chip vendors would not have invested so much money into this technology if they saw no likely market for it. Formation of the Linux Foundation’s Confidential Computing Consortium (CCC) is another example of how the industry is interested in finding common models for use of confidential computing and encouraging open source projects to employ these technologies[1].
open source: like blockchain, confidential computing is one of those technologies where it’s an absolute no-brainer to use open source. If you are going to run sensitive applications, you need to trust what’s doing the running for you. That’s not just the CPU and firmware, but the framework which supports the actual execution of your workload within the TEE. It’s all very well saying “I don’t trust the host machine and its software stack so I’m going to use a TEE”, but if you don’t have visibility into the TEE software environment, then you’re just swapping one type of software opacity for another. Open source support for TEEs allows you or the community – in fact, you and the community – to check and audit what you’re running in a way which is impossible for proprietary software. This is why the CCC sits within the Linux Foundation (which is committed to the open development model) and is encouraging TEE-related software projects to join and to go open source (if they weren’t already).

Security by default is a promise that we’ve been hearing for decades now, and it hasn’t arrived yet. Honestly, I’m not sure it ever will. But as new technologies become available, security ubiquity for particular use cases becomes more practical and more expected within the industry. It seems that confidential computing is ready to be the next big change – and you, dear reader, can join the revolution (it’s open source, after all).

5 security tips from Santa

Have you been naughty or nice this year?

If you’re reading this in 2019, it’s less than a month to Christmas (as celebrated according to the Western Christian calendar), or Christmas has just passed. Let’s assume that it’s the former, and that, like all children and IT professionals, it’s time to write your letter to Santa/St Nick/Father Christmas. Don’t forget, those who have been good get nice presents, and those who don’t get coal. Coal is not a clean-burning fuel these days, and with climate change well and truly upon us[1], you don’t want to be going for the latter option.

Think back to all of the good security practices you’ve adopted over the past 11 or so months. And then think back to all the bad security practices you’ve adopted when you should have been doing the right thing. Oh, dear. It’s not looking good for you, is it?

Here’s the good news, though: unless you’re reading this very, very close to Christmas itself[2], then there’s time to make amends. Here’s a list of useful security tips and practices that Santa follows, and which are therefore bound to put you on his “good” side.

Use a password manager

Santa is very careful with his passwords. Here’s a little secret: from time to time, rather than have his elves handcraft every little present, he sources his gifts from other parties. I’m not suggesting that he pays market rates (he’s ordering in bulk, and he has a very, very good credit rating), but he uses lots of different suppliers, and he’s aware that not all of them take security as seriously as he does. He doesn’t want all of his account logins to be leaked if one of his suppliers is hacked, so he uses separate passwords for each account. Now, Santa, being Santa, could remember all of these details if he wanted to, and even generate passwords that meet all the relevant complexity requirements for each site, but he uses an open source password manager for safety, and for succession planning[3].

Manage personal information properly

You may work for a large company, organisation or government, and you may think that you have lots of customers and associated data, but consider Santa. He manages, or has managed, names, dates of birth, addresses, hobby, shoe sizes, colour preferences and other personal data for literally every person on Earth. That’s an awful lot of sensitive data, and it needs to be protected. When people grow too old for presents from Santa[4], he needs to delete their data securely. Santa may well have been the archetypal GDPR Data Controller, and he needs to be very careful who and what can access the data that he holds. Of course, he encrypts all the data, and is very careful about key management. He’s also very aware of the dangers associated with Cold Boot Attacks (given the average temperature around his relevance), so he ensures that data is properly wiped before shutdown.

Measure and mitigate risk

Santa knows all about risk. He has complex systems for ordering, fulfilment, travel planning, logistics and delivery that are the envy of most of the world. He understands what impact failure in any particular part of the supply chain can have on his customers: mainly children and IT professionals. He quantifies risk, recalculating on a regular basis to ensure that he is up to date with possible vulnerabilities, and ready with mitigations.

Patch frequently, but carefully

Santa absolutely cannot afford for his systems to go down, particularly around his most busy period. He has established processes to ensure that the concerns of security are balanced with the needs of the business[5]. He knows that sometimes, business continuity must take priority, and that on other occasions, the impact of a security breach would be so major that patches just have to be applied. He tells people what he wants, and listens to their views, taking them into account where he can. In other words, he embraces open management, delegating decisions, where possible, to the sets of people who are best positioned to make the call, and only intervenes when asked for an executive decision, or when exceptions arise. Santa is a very enlightened manager.

Embrace diversity

One of the useful benefits of running a global operation is that Santa values diversity. Old or young (at heart), male, female or gender-neutral, neuro-typical or neuro-diverse, of whatever culture, sexuality, race, ability, creed or nose-colour, Santa takes into account his stakeholders and their views on what might go wrong. What a fantastic set of viewpoints Santa has available to him. And, for an Aging White Guy, he’s surprisingly hip to the opportunities for security practices that a wide and diverse set of opinions and experiences can bring[6].

Summary

Here’s my advice. Be like Santa, and adopt at least some of his security practices yourself. You’ll have a much better opportunity of getting onto his good side, and that’s going to go down well not just with Santa, but also your employer, who is just certain to give you a nice bonus, right? And if not, well, it’s not too late to write that letter directly to Santa himself.

1 – if you have a problem with this statement, then either you need to find another blog, or you’re reading this in the far future, where all our climate problems have been solved. I hope.

2 – or you dwell in one of those cultures where Santa visits quite early in December.

3 – a high-flying goose in the face can do terrible damage to a fast-moving reindeer, and if the sleigh were to crash, what then…?

4 – not me!

5 – Santa doesn’t refer to it as a “business”, but he’s happy for us to call it that so that we can model our own experience on his. He’s nice like that.

6 – though Santa would never use the phrase “hip to the opportunities”. He’s way too cool for that.

Who do you trust on trust?

(I’m hoping it’s me.)

I’ve been writing about trust on this blog for a little over two years now. It’s not the only topic, but it’s one about which I’m passionate. I’ve been thinking about issues around trust, particularly in regards to computing and security, for nearly 20 years, and it’s something I care about a lot. I care about it so much that I’m writing a book about it.

In fact, I care about it maybe a little too much. I was at a conference earlier this year and – in a move that will come as little surprise to regular readers of this blog[1] – actually ended up getting quite cross about it. The problem is that lots of people talk about trust, but they either don’t really know what they’re talking about, or they really don’t know what they’re talking about. To be clear, I mean different things by those two statements. Some people know their subject, but their subject isn’t really trust. Other people don’t know their subject, but then again, the thing they think they’re talking about often isn’t trust either. Some people talk about “zero trust“, when I really need to look beyond that concept, and discuss implicit vs explicit trust. People ignore the importance of establishing trust. People ignore the importance of decaying trust. People assume that transitive trust is the same as direct trust. People ignore context. All of these are important, and arguably, its not their fault. There’s actually very little detailed writing about trust outside the social sciences. Given how much discussion there is of trust, trusted computing, trusted systems and the like within the world of IT security, there’s astonishingly little theoretical underpinning of the concept, which means that there’s very little agreement as to what is really meant. And, it turns out, although it seems that trust within the social sciences is quite like trust within computing, it really isn’t.

Anyway, there were people at this conference earlier this year who said things about trust which strongly suggested to me that it would be helpful if there were a good underpinning that people could read and discuss and disagree with: a book, in fact, about trust in computing. I got so annoyed that I made a decision to tell two people – my boss and one of the editors of Opensource.com – that I planned to write a book about it. I’m not sure whether they really believed me, but I ended up putting together a Table of Contents. And then looking for a publisher, and then sending several publishers a copy of the ToC and some further thoughts about what a book might look like, and word count estimates, and a list of possible reader types and markets.

And then someone offered me a contract. This was a little bit of surprise, but after some discussion and negotiation, I’m now contracted to write a book on trust for Wiley. I’m absolutely going to continue to publish this blog, and I’ll continue to write about trust here. And, on occasion, something a little bit more random. I don’t pretend to know everything about the subject, and writing about it here allows me to explore some of the more tricky issues. I hope you’ll join me for the ride – and if you have suggestions or questions, I’d love to hear about them.

1 – or my wife and kids.

“Unhackability” or just poor journalism?

An over-extended analogy about seat belts and passwords.

I recently saw a tagline for a brief article in a very reputable British newspaper which was “Four easy steps to unhackability”. It did two things to me:

it made me die a little inside;
it made me really quite angry.

The latter could be partly related to the fact that it was a Friday evening and I felt that I deserved a beer, and the former to the amount of time I’d spent during the week mastering our new expenses system, but whatever. The problem is that there is no “unhackable”. Just as there is no “secure”.

This, I suppose, is really what made me die a little inside. If journalists are going to write these sorts of articles, then they should know better. And if they don’t, the editor shouldn’t let them write the article. And if they didn’t write the tagline, then whoever did should be contacted, shouted at, and forced to rewrite it. And provide an apology. Preferably a public one.

The article was about good password practice, and though short, contained sensible advice. For a more complete (and, dare I say, wittier) guide, see my article The gift that keeps on giving: passwords. I was happy about the advice, but far, far from happy about the title. Let’s employ that most dangerous of techniques: an analogy. If, say, someone wrote an article on motoring about how to use seat belts with the tagline “Four steps to uninjureability”, anyone who knew anything about cars would be up in arms, because it’s clear that seat belts, useful as they are, and injury-reducing as they are, do not protect you from all injury when driving, even if employed perfectly correctly. This is what made me angry, because the password article seemed to suggest that good passwords would stop you being technologically injured (see: here’s why we don’t let people play with analogies).

Because, although most people might understand about seat belts, fewer people – many fewer people – have a good idea about computer security. Even the people who do understand lots about computer security aren’t immune from being hacked, however well they pursue good practice (and, to reiterate, the advice in the article was good practice). It’s the same with motoring – even people who use their seat belts assiduously, and drive within the speed limit, and follow all the rules of the road, aren’t immune from injury. In fact, no: motoring is better, by at least one measure, which is that (in most cases at least), there aren’t a whole bunch of people whose main aim in life is to injure as many other motorists as they can. As opposed to the world of technology, where there really is a goodly number of not-so-goodly people out there on the Internet whose main aim in life is to hack[1] other people’s computers and do bad things with their data and resources.

As my friend Cathy said, “it gives people a false sense of security”.

Some actual advice

Computer security is about several things, about which the following come immediately to mind:

layers: the more measures or layers of security that you have in place, the better your chances of not being hacked;
timeliness: I’m not sure how many times I’ve said this, but you need to keep your systems up-to-date. This may seem like an unnecessary hassle, but the older your software is, the more likely that there are known vulnerabilities, and the more likely that a hacker will be able to compromise your system;
awareness: sometimes we just need to be aware that emails can be malicious, or that that phone-call purporting to be from your Internet Service Provider may in fact be from someone trying to do bad things to your computer[2];
reaction: if you realise something’s wrong, don’t keep doing it. It’s usually best to step away from the keyboard and turn off the machine before more damage is done.

There: a set of pieces of advice, with no ridiculous claims about how well they’ll serve you. I’ll save that for another, lazier article (or hopefully not).

1 – mean “crack”, but I’ve pretty much given up on trying to enforce this distinction now. If you’re with me and feel sad about this, nod quietly to yourself and go to enjoy that beer I mentioned at the beginning of the article: you deserve it.

2 – don’t even start me on using random USB drives – I even had an anxiety dream about this last night.

No article this week

Sorry – busy and recovering from illness.

Enarx goes multi-platform

Now with added SGX!

Yesterday, Nathaniel McCallum and I presented a session “Confidential Computing and Enarx” at Open Source Summit Europe. As well as some new information on the architectural components for an Enarx deployment, we had a new demo. What’s exciting about this demo was that it shows off attestation and encryption on Intel’s SGX. Our initial work focussed on AMD’s SEV, so this is our first working multi-platform work flow. We’re very excited, and particularly as this week a number of the team will be attending the first face to face meetings of the Confidential Computing Consortium, at which we’ll be submitting Enarx as a project for contribution to the Consortium.

The demo had been the work of several people, but I’d like to call out Lily Sturmann in particular, who got things working late at night her time, with little time to spare.

What’s particularly important about this news is that SGX has a very different approach to providing a TEE compared with the other technology on which Enarx was previously concentrating, SEV. Whereas SEV provides a VM-based model for a TEE, SGX works at the process level. Each approach has different advantages and offers different challenges, and the very different models that they espouse mean that developers wishing to target TEEs have some tricky decisions to make about which to choose: the run-time models are so different that developing for both isn’t really an option. Add to that the significant differences in attestation models, and there’s no easy way to address more than one silicon platform at a time.

Which is where Enarx comes in. Enarx will provide platform independence both for attestation and run-time, on process-based TEEs (like SGX) and VM-based TEEs (like SEV). Our work on SEV and SGX is far from done, but also we plan to support more silicon platforms as they become available. On the attestation side (which we demoed yesterday), we’ll provide software to abstract away the different approaches. On the run-time side, we’ll provide a W3C standardised WebAssembly environment to allow you to choose at deployment time what host you want to execute your application on, rather than having to choose at development time where you’ll be running your code.

This article has sounded a little like a marketing pitch, for which I apologise. As one of the founders of the project, alongside Nathaniel, I’m passionate about Enarx, and would love you, the reader, to become passionate about it, too. Please visit enarx.io for more information – we’d love to tell you more about our passion.

What’s a Trusted Compute Base?

Tamper-evidence, auditability and measurability are three important properties.

A few months ago, in an article called “Turtles – and chains of trust“, I briefly mentioned Trusted Compute Bases, or TCBs, but then didn’t go any deeper. I had a bit of a search across the articles on this blog, and realised that I’ve never gone into this topic in much detail, which feels like a mistake, so I’m going to do it now.

First of all, let’s think about computer systems. When I talk about systems, I’m being both quite specific (see Systems security – why it matters) and quite broad (I don’t just mean computer that sits on your desk or in a data centre, but include phones, routers, aircraft navigation devices – pretty much anything that has a set of chips inside it). There are surely some systems that you don’t rely on too much to do important things, but in most cases, you’re going to care if they go wrong, or, more relevant to this discussion, if they get compromised. Even the most benign of systems – a smart light-bulb, for instance – can become a nightmare if compromised. Even if you don’t particularly care whether you can continue to use it in the way it was intended, there are still worries about its misuse in the case of compromise:

it may become a “jumping off point” for malicious attacks into your network or other systems;
it may be used as part of a botnet, piggybacking on your network to attack other systems (leading to sanctions against your legitimate systems from outside);
it may be used as part of a botnet, using up resources such as network bandwidth, storage or electricity (leading to resource constraints or increased charges).

For any systems dealing with sensitive data – anything from your messages to loved ones on your phone through intellectual property secrets for a manufacturing organisation through to National Security data for government department – these issues are compounded. In order to protect your system, you can’t just say “this system is secure” (lovely as that would be). What can you do to start making statement about the general security of a system?

The stack

Systems consist of multiple components, and modern computing systems are typically composed from multiple layers (one of my favourite xkcd comics, Stack, shows some of them). What’s relevant from the point of view of this article is that, on the whole, the different layers of the stack start up – boot up – from the bottom upwards. This means, following the “bottom turtle” rule (see the Turtles article referenced above), that we need to ensure that the bottom layer is as secure as possible. In fact, in order to build a system in which we can have assurance that it will behave as expected and designed (in other words, a system in which we can have a trust relationship), we need to build a Trusted Compute Base. This should have at least the following set of properties: tamper-evidence, auditability and measurability, all of which are related to each other.

Tamper-evidence

We want to know if the TCB – on which we are building everything else – has a problem. Specifically, we need a set of layers or components that we are pretty sure have not been compromised, or which, if compromised, will be tamper-evident:

fail in expected ways,
refuse to start, or
flag that they have been compromised.

It turns out that this is not easy, and typically becomes more difficult as you move up the stack – partly because you’re adding more layers, and partly because those layers tend to get more complex.

Our TCB should have the properties listed above (around failure, refusing to start or compromise-flagging), and be as small as possible. This seems the wrong way around: surely you would want to ensure that as much of your system was trusted as possible? In fact, what you want is a small, easily measurable and easily auditable TCB on which you can build the rest of your system – from which you can build a “chain of trust” to the other parts of your system about which you care. Auditability and measurability are the other two properties that you want in a TCB, and these two properties are why open source is a very useful tool in your toolkit when building a TCB.

Auditability (and open source)

Auditability means that you – or someone else who you trust to do the job – can look into the various components of the TCB and assure yourself that they have been written, compiled and are executing properly. As I explained in Of projects, products and (security) community, the person may not always be you, or even someone in your organisation, but if you’re using widely deployed open source software, the rest of the community can be doing that auditing for you, which is a win for you and – if you contribute your knowledge back into the community – for everybody else as well.

Auditability typically gets harder the further you go down the stack – partly because you’re getting closer and closer to bits – ones and zeros – and to actual electrons, and partly because there is very little truly open source hardware out there at the moment. However, the more that we can see and audit of the TCB, the more confidence we can have in it as a building block for the rest of our system.

Measurability (and open source)

The other thing you want to be able to do is ensure that your TCB really is your TCB. Tamper-evidence is related to this, but that’s a run-time property only (for software components, at least). Being able to measure when you provision your system and then to check that what you originally loaded is still what you think it should be when you boot it is a very important property of a TCB. If what you’re running is open source, you can check it yourself, against your own measurements and those of the community, and if changes are made – by you or others – those changes can be checked (as part of auditing) and then propagated through measurement checking to the rest of the community. Equally important – and much more difficult – is run-time measurability. This turns out to be very difficult to do, although there are some techniques emerging which are beginning to get traction – for now, we tend to rely on tamper-evidence, which is easier in hardware than software.

Summary

Trusted Compute Bases (TCBs) are a key concept in building systems that we hope will behave in ways we expect – or allow us to find out when they are not. Tamper-evidence, auditability and measurability are three important properties that they should display, and it turns out that open source is an important factor in helping us ensure two of those.