Confidential Computing is charting new territory in the digital world by chaining attestation and authentication, something which has been known to the legal system for centuries.
At Profian, we are familiar with the concept of authentication. We do it multiple times daily, logging into our favorite portals like Google, Facebook or LinkedIn.
Authentication establishes who we are so that the software we interact with can decide what services to offer and what we are allowed to do.
There are three ways in which we can establish our identity:
- By something we know – a password, for example
- By something we have – a hardware device with a token, phone, keyfob or smart card
- By something we are – our biometrics: fingerprints and retina scans
Biometrics have been quite complex to implement, so in most situations, we use a combination of something we know and something we have to authenticate.
Multi-factor authentication is a gold standard for authenticating humans nowadays. Yes, in some cases, humans have to delegate complex passwords we can’t remember anymore to a password vault and unlock it as a part of the authentication process, but this is not the point. The point is that humans are individuals, and to establish our identity, we need to authenticate.
Now let’s imagine something from the near future. You bought a robot that will do shopping on your behalf. You just tell it what to do, follow your instructions, go shopping, and bring back whatever you have requested. So the robot is definitely not you, but on the other hand, acts on your behalf. It needs the power and resources to act and fulfill its duties – it needs agency. To give it agency, you need to define the rules but also empower the robot to make decisions on its own and represent you while shopping. In this scenario, there are a couple of authentication questions to ponder.
What identity will the robot operate under, yours or its own?
Will you share your PIN and credit card with the robot, or will you generate a new one for this robot?
If it is your personal robot that you often use and think of as your clone, you might decide to share your credit cards and PINs, though it would not be the best security practice. A better approach would be to give it an identity and credentials to act independently. But managing this identity becomes an extra burden.
Now imagine that instead of buying your own robot, you hire one off the street, like a taxi, tell it what to do and send it shopping. Will you hand it a credit card? Probably not. You would want to give it as little of your personal information as possible. In this case, it might be better for such a robot to have an identity defined by the manufacturer and somehow link it to you while it is shopping on your behalf.
So off the robot goes shopping! The robot picks out the groceries on your list and arrives at the register to pay on your behalf. At this point, the shop is aware the robot is shopping on your behalf but is it authorized to use your payment method? A traditional way of establishing identity, i.e., authentication, in this case, does not work well since it is a conjunction of the identity of the robot and your assignment that matter at that moment. And when I say “assignment”, I mean a combination of the:
- shopping list
- payment information
- instructions and preferences related to the above
That is, all the things you provide to the robot to give it agency to operate on your behalf.
Welcome to the concept of attestation!
Let’s now imagine that while you hired a robot off the street, the app on your phone connected to the robot and requested a cryptographically signed report proving that the robot is what it claims to be (and not a human dressed as a robot). After checking all the signatures, the app will send you the preferences, shopping lists and payment information and bind this robot to you for the next shopping trip. The data you give to the robot electronically will be the “assignment.” as explained above. It will be sealed and signed by your identity. When the robot arrives at the shop, the electronic cashier will verify all the signatures and attest that:
- the robot has not been tampered with
- the task was given to the untempered robot
- the task is legitimate and signed by you
Only after checking all these properties will the cashier be comfortable accepting the robot’s payment and selling the groceries on your behalf.
So, in other words, attestation is a process of establishing proof that something is legitimate. And to establish such evidence, some attesting, trusted party conducts a series of verifications making sure that no step has gone rogue.
Now let’s generalize for some real-world applications of attestation.
Attestation becomes handy when an electronic identity needs to act temporarily on behalf of another human or not human identity. The example with robots is quite visual but futuristic. In real life, we can already find situations when attestation leads to a new temporary identity. For example, in the case of will or power of attorney, a person grants permission to represent their interests and execute on their behalf. The lawyer’s identity is not sufficient. The will, by itself, is also not enough. The combination of the person’s identity, the lawyer’s identity and the legal recording of the document make the will or power of attorney trustworthy. Asserting that all the participants are legitimate and the paper was created correctly, signed and recorded – is an attestation. And the attestation grants the lawyer the temporary identity of “the one who acts on behalf of the client.”
Attestation dynamically synthesizes a temporary identity to execute important tasks.
The concept of attestation is central to Confidential Computing, which enables deploying a workload into a system with a modern chipset and running such a workload in an encrypted environment isolated from its operating system. Workloads, once deployed, need to connect to other programs and services. One can do this by embedding the identity and credentials into a workload. But with such an approach, there is a leap of faith that the workload was not tampered with and no one stole its identity. Instead, attesting that:
- the system has not been tampered with
- the workload runtime has not been tampered with
- the workload itself has not been tampered with
It is a way to build a sequence of proofs that renders sufficient information to synthesize a temporary identity dynamically. We can use such identity for authentication in the traditional authentication flows.
How is it done? My upcoming series of blogs will help to answer this question.