When it comes to software and systems, attestation involves presenting evidence to verify the integrity of the system.
Attestation has come up in previous podcast episodes on confidential computing and software supply chain security. Here, we take a deeper dive into why it's important and talk about some different approaches.
In this episode, we explore attestation and its role in creating trust in software and computing environments with Marcella Melara, a Security Researcher with Intel Labs, and Vinnie Scarlata, a Principal Engineer in the Security & Privacy Research Lab in Intel Labs.
Katherine Druckman:
Starting with the basics, Vinnie, what is attestation as it relates to software and trusted computing? What are the different types of attestation and the applications of each type?
Vinnie Scarlata:
Attestation fundamentally is just to assert a claim, but depending on the context, you get different answers on what’s being claimed and who’s claiming. In the context of software or software attestation, the author or some trusted party or third-party evaluator, maybe a governing body or tool chain, will make statements about the software, what its origins are, maybe what its compositions are, etc.
In trusted computing or confidential computing, remote attestation there will be some secure element in a platform making an assertion about what specific software is running, maybe how the platform is configured, statements about whether it's up to date or not, whether it's in good standing, if it's genuine hardware, and then you can put them together for a statement that a platform is running certain software and this is why you should trust that software. You know you can trust that endpoint.
Katherine Druckman:
Marcela, why is software attestation especially important in open source software?
Marcela Melara:
Open source software can have the potential for a large number of contributors, even small projects. The whole idea is to get input.
Katherine Druckman:
In open source, you want contribution from the outside world.
Marcela Melara:
So, these issues come up when you have many different practices around what a contribution looks like and what types of contributions you accept to your project. There are larger projects managed under foundations like the Linux Foundation*, and they tend to follow a set of consistent practices, codes of conduct and that sort of thing, and that you can see in the individual repositories. In general, some of the devs who contribute are vetted, but vetting people at a global scale, especially if you're a small business or project, is quite difficult. So a lot of open source contributors aren't vetted, and it ends up being up to the maintainers to do proper code reviews, follow security best practices and secure their project and their little part of the supply chain.
Katherine Druckman:
Be careful before you hit merge!
How is software attestation related to the idea of provenance in software? There’s a supply chain and we want to track the life cycle and where the software comes from. How does attestation relate to that?
Marcela Melara:
In the software supply chain, we use provenance in a few different ways. What you're describing is the dictionary definition of provenance, where an attestation about a software artifact will tell us its origins, the process or history of it and how it came to be. It could contain information about who touched the software before it got to you.
Katherine Druckman:
We want its entire life story, right?
Marcela Melara:
The attestations are essentially the documentation for that life story, for that whole life cycle that you're interested in understanding. But I wanted to point out, because this comes up almost interchangeably, that there's also SLSA provenance, a very specific data format for a type of attestation. We have the general idea of provenance, and then there's also SLSA provenance in the software space that describes the build process and setup for software producers, vendors, and how a piece of software is built. It's a very specific instance of more general provenance.
Katherine Druckman:
When you're buying a piece of art, the way you attest to its provenance is its life story. How did it get to the current owner and the previous owners? Maybe there are receipts along the way if somebody bought a piece of art 100 years ago and retained a receipt and then it changed hands. Is it fair to make the comparison that a software attestation is sort of like keeping receipts?
Marcela Melara:
I think the receipt analogy is pretty close. The difference being that you know the receipt can have different information. Maybe you care about everything that's in your receipt or not. But yeah, generally I think that that's a fair comparison.
Katherine Druckman:
Now that we've defined attestation, how does attestation help ensure integrity and build trust? Software communities are increasingly concerned about building trust, how does attestation help?
Vinnie Scarlata:
I'll start with the remote attestation piece.
When you interact with a remote platform, particularly if it's one you don't own, remote attestation aims to give you building blocks for establishing trust. Is the silicon genuine? That speaks to the hardware supply chain. Is there any firmware on it that needs to be updated? We spend a lot of money on very fancy security features that are supposed to protect our platforms. Are they turned on? Are they configured properly? These are all critical pieces reflected in the attestation, and then when you get to the top of the stack, it will identify the software that you're running on that execution engine, be it at the full platform scope or at a trusted execution environment scope. But it only tells you the identity of the software. It does not help you know whether you should trust that software. And that's where we transition over to software attestation.
Marcela Melara:
In general attestations convey information so a consumer or user of the software can check and decide if they trust the software using the attestation. I always like to come back to the question of, “What does it actually mean to trust software?” Like Vinnie said, maybe it's just enough to know the identity of the software. Does the software that running on your platform match what I expected? If that's all you care about, maybe that's enough. Maybe all the consumer cares about is who wrote the software. In that case, a super simple digital signature might be enough.
Once ask more complex questions around what the components are, what the dependencies are, you get into the software supply chain. Then maybe we need to include an software bill of materials (SBOM) in the attestation. If I want to know something as fine-grained or specific like whether my code will have certain bugs or not have certain bugs, then attestation can help. Ultimately, it comes down to the type and quality of the information contained in the attestation for the user to build trust.
Vinnie Scarlata:
You asked about integrity. Part of identifying the software is that we're not talking about product XYZ version two, the attestations are much stronger. They're typically cryptographic hashes of what’s running, so if it’s been tampered with, either in distribution or between running or while it's running, that will be reflected in the “software identity.” Typically, we refer to them as measurements of the software. At that point, we can detect tampering and integrity violations of the software at any point in that that chain of remote attestations and software attestations.
Katherine Druckman:
Do you have any community calls to action?
Vinnie Scarlata:
There are a bunch of different standards organizations working on the task, which means that there's not a there's not as much collaboration as we need. Even within just the remote attestation and the trusted computing area, only recently have the major players to started doing the kind of inter-standards organization work that provides great results. There's an opportunity to also do more work between the software world and the trusted computing world. I think both would recognize the value in collaboration, but it's a reasonable argument that not until recently did it really make sense. I mean, both stories have to mature enough before you can have those larger conversations. We're at an exciting time now -- we can really start doing cross-domain work.
Marcela Melara:
Completely agree. I've started seeing that not only in my own work, but also in conversation with the open source software community, the interest toward what we could do with Trusted Platform Module (TPM) attestations or other trusted compute work, and what are the implications for software?
I'm glad that we talked about attestation in a more holistic sense...being able to include the hardware side and the remote attestation side is a unique opportunity.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.