Gufran Mirza — Writing

No Rule Was Broken

Wed, 05 Aug 2026 00:00:00 GMT

Disclaimer: The views expressed here are my own and do not represent those of my current or former employers.

Why every control sees the request and misses the situation

Every control around the browser sees where you went and what bytes moved. Identity tells you whose credentials were used, never who was driving. A human, or an AI agent?

None of them holds the situation: what the page is, who is acting, and why. That gap is where the attacks that matter now live.

After enough time with policy engines, DLP rules, and the incident write-ups that follow them, I keep landing on the same conclusion:

The unit of risk is no longer the file.

And it's no longer the request.

It's the situation.

The situation, not the request

Imagine an analyst signed into Snowflake on a corporate laptop. The credentials are valid. The session is real. The query is COPY INTO, which is Snowflake's own export feature, run thousands of times a day by people doing their jobs.

Nothing here is malformed. Every field checks out. What no field records is that the credentials were lifted by infostealer malware from an account with no multi-factor, and that the table on its way out is the customer list.

Mandiant traced every incident in the 2024 campaign to exactly that. Around 165 organizations exposed. Snowflake itself was never broken.

If you inspect the request afterward, it still does not look alarming. A valid user ran a valid query against a valid endpoint. That's exactly the problem.

The dangerous part is not the request. It's what the request means. A whole customer table leaving at once is a fact about the situation, not about the query. "Bulk" appears nowhere in the bytes. Neither does "customer data." Neither does "this login was stolen last week."

The engine holds the request in full and still cannot reach the one fact that decides the case.

A lot of the security stack is built around request-shaped thinking. This URL was visited. That file type was uploaded. This pattern matched.

But the attacks that matter are not request-shaped. They are situation-shaped. A page loads. A prompt appears. Someone reads it and believes it, or something reads it and acts on it. A button gets clicked. A session that was already valid does something it has never done before.

Each piece is ordinary on its own. The danger only shows up when you hold them together and ask what is going on here.

Nothing in the stack holds them together. That is the missing layer. DLP sees the bytes. It never sees the situation around them.

The perimeter moved into meaning

For thirty years, offense went after code, and defense answered in kind. It worked, because an attack and its intent traveled together. Malware looked like malware. An exploit looked like an exploit.

Then the ground kept moving. First the binary mattered. Then the network. Then the browser became the work environment, and control moved up into identity, SaaS, extensions, and browser-native DLP. Now I believe the center of gravity is shifting again.

The mistake is to call this an AI problem. It is more concrete than that. The new perimeter is the moment of the action itself: what the page is, what it is asking for, who is acting, what is about to leave, and whether those things fit together.

The modern intrusion barely touches a bug. It goes after people and the trust between them.

ClickFix talks a user into pasting a command into PowerShell, on a legitimate site the attacker quietly took over. Consent phishing talks a user into clicking Allow on a real screen, after which Microsoft notes that resetting the password will not help. Golden SAML is one settings change on a domain, made from an ordinary admin console over a properly authenticated session, and it hands the front door to a stranger.

Each one is a sanctioned action, aimed at a harmful end. That is the deeper shift. Attackers are no longer stumbling into same-shape attacks. They are manufacturing them, dressing an intrusion in the clothes of ordinary work on purpose. And they no longer have to do it by hand. An agent driving the browser will do it for them, on the user's own credentials, the moment a page can talk it into the act.

That's why I think this is not a gap in any one product. The tell has moved into meaning, and shape-matching cannot follow it there.

Rules can only describe form

Every control in the stack sees a piece of the picture. Pattern and entropy scanners can tell you a string looks like a secret. Useful. Identity can tell you who signed in, from what device, with what factors. Also useful. Reputation and URL filtering can tell you a domain is known bad. Still useful.

But none of those, on its own, gives you a coherent read on what is actually happening in front of the user. Increasingly, that's the thing that matters.

You can watch teams live inside the gap. The standard tuning advice is the same everywhere: narrow your expressions by hand until the noise is bearable, which is a quiet admission that the method is noisy by design. Measured against the SecretBench corpus, these scanners flagged 84.5% false positives.

Tighten the rules and real work stops. Loosen them and the signal drowns. There is no setting in the middle, because the missing piece is not a setting.

That isn't really a criticism of DLP. It's a statement about the vocabulary. A rule can name a URL, a method, a file type, a signed-in user, a device, and whatever a regular expression can pull out of the bytes. That is the entire dictionary.

Every rule anyone has ever written is built from those words, and all of them describe the form of a request. Not one of them describes what the request is for.

So the administrator gets two settings for any action, block or allow, and no way to write the only rule that would actually be safe. Allow this, unless it means something dangerous. Block paste into ChatGPT and people move to a personal account in the same browser. Allow it and you have no idea what left.

When a valid session exports a table, or a real consent screen hands over a mailbox, knowing who signed in is necessary information.

It is no longer sufficient.

The model advises, the engine decides

The missing layer is the thing that holds the situation. I think it has to do four things well, and the fourth is the one the other three depend on.

First, it has to read meaning rather than bytes. Not another matcher over the payload, but a judgment about the moment. Is this actually customer data. Is this page actually asking for more than it should.

Second, it has to know who is acting, and on whose authority. A person exporting a table, an agent doing it because they were asked, and an agent doing it because a page told it to are the same request three times over. Same session, same credentials, same bytes. Only the provenance differs. Identity does not answer this. It tells you whose credentials were used, and nothing about who was driving.

Third, it has to stand where the situation is visible, and run where the data already is. A network filter sees encrypted traffic and little else. A server-side audit log sees the action after it is done, one application at a time. The browser sees the page as rendered, what is acting on it, and who is signed in, in the moment, across every site including the long tail no ruleset reaches.

If you want to weigh a situation you have to stand where the situation is. That is the browser or nowhere.

And a tool whose job is to stop data from leaving cannot work by making the data leave. Ship every page to a cloud model for a verdict and you have built the exact leak you set out to prevent, with surveillance on top. So the reading happens on the person's own machine.

That used to be impossible. The model was always too large to sit on the machine reading the page. That changed fast. WebGPU opened the GPU to web code, quantization packed capable models into a couple of gigabytes, and a browser now runs one at around forty words a second, with nothing leaving the device.

And fourth, it has to advise and never act. This is the constraint the whole design rests on.

Anything that can understand a page can be talked to. Anything that can be talked to can be talked into things. Brave's researchers showed a hidden note on a page turning an AI browser against its own user, reading mail and sending it out. It is the first item on OWASP's list, and not a bug a patch removes.

So do not give it the keys. Let the model look and think. Let a plain, unpersuadable engine decide and act.

The model's read can only ever raise a concern. It advises, it never authorizes. The deterministic policy holds whatever the model says, or is tricked into saying.

Hold to that and injection loses its reward. Fool the model and the worst you get is a wrong opinion. You gained nothing, because it could never do anything.

There are really two ways to frame this. One is content inspection with a smarter matcher, which is where most of the industry is heading. That will catch more secrets in more documents. But it is the same vocabulary with a bigger dictionary, and it still cannot say the word "bulk."

The other is situational judgment sitting on top of deterministic policy.

Cheap triggers do the watching, because most of what matters announces itself plainly. A query returning a hundred thousand rows. A domain's login settings being edited. A page writing a shell command to the clipboard. You call on the model only at those moments, and only for the judgment a rule cannot generalize.

That would let you ask far better questions than most teams can ask today. Is this export routine for this person, or the first of its kind? Did this page turn into something else after it loaded? Was this admin change consistent with anything anybody intended?

A category, not a feature

Widen the aperture and the same framework starts to matter elsewhere. Which documents were pulled into context before the assistant drafted the memo? Which local files became cloud inputs? Which tool was invoked, and on whose behalf?

Once work becomes composable, the situation becomes the control surface.

Right now most security stacks answer those questions indirectly, if at all. That's why this feels like a category opening, not a missing feature.

Historically, new perimeters create new companies, because the telemetry changes and the control surface changes with it. Browser-native work produced enterprise browsers. Cloud-native infrastructure produced cloud-native security companies. They were not feature extensions of what came before. They were responses to a different environment.

Situational security has that same feel. The telemetry is different from DLP. The unit of analysis is different from identity. The control problem is different from URL filtering. You are trying to understand what is happening to a person, in a moment, in context.

It is worth saying plainly what this does not solve. It goes blind where the page does, because tools that paint themselves onto a canvas show a browser almost nothing to read. It sees automation, not the intent to hide it: a declared agent can be held to a policy, but an agent driving Chrome over the DevTools Protocol looks exactly like a person to the page, and an agent that spawns its own headless browser was never inside yours to begin with.

And it is approximate, which is why it belongs on the gentle end of the response. Asking, warning, recording. Never silently slamming a door.

None of that dents the argument. It fences it.

If you only scan the bytes, you miss what the bytes are for. If you only check the domain, you miss the page that changed after it loaded. If you only watch identity, you miss what a valid session did with it. If you only log the API call, you miss the person who was talked into making it.

The missing layer is the situation itself.

My guess is that this will look obvious in hindsight. We'll talk about situational context in the browser the way we now talk about identity, isolation, or posture. A distinct layer that had to emerge once the environment changed.

But right now the space is still open enough that the categories blur together. One company matches strings. Another checks domains. Another governs identity. Another isolates the session. All useful. None of them holds the situation.

That's the opening.

The situation is right there, in the browser, fully visible. Security needs to start reading it.

TLS with Remote Attestation (aTLS) | Machine-to-Machine Secure Channel

Sat, 20 Apr 2024 00:00:00 GMT

1. Introduction

aTLS introduces a set of protocol extensions to the TLS 1.3 handshake, enabling the binding of TLS authentication keys to remote attestation sessions.

This allows peers to authenticate themselves using "attestation credentials," comprising platform evidence and key attestation, enhancing security metrics during TLS channel setup.

These extensions are technology-agnostic, accommodating various attestation formats, and support both background-check and passport topologies for authentication. Additionally, the specification allows for one-way and mutual authentication using attestation credentials, with attestation topologies at each peer being independent.

2. Conventions and Terminology

The following terms are used in this document:

TLS Identity Key (TIK): A cryptographic key used by one of the peers to authenticate itself during the TLS handshake.
TIK-C, TIK-S: The TIK that identifies the client or the server, respectively.
TIK-C-ID, TIK-S-ID: An identifier for TIK-C or respectively, TIK-S. This may be a fingerprint (cryptographic hash) of the public key, but other implementations are possible.

3. Overview

The goal is to link the authenticated key exchange of TLS with an interleaved remote attestation session in such a way that the key used to sign the handshake can be proven to be residing within the boundaries of an attested TEE. The requirement is that the attester can provide evidence containing the security status of both the signing key and the platform that is hosting it. The associated security goal is to obtain such binding so that no replay, relay or splicing from an adversary is possible.

TEE attestation is provided by a Platform Attestation Token (PAT) signed by the attester's "attesting environment". Among other security metrics, the PAT contains evidence about the integrity of a "Key Attestation Service" executing within the TEE which issues a Key Attestation Token (KAT) for the TLS handshake signing key (TIK). The protocol's security relies on the verifiable binding between these two logically separate units of evidence.

4. Attestation Extensions

As typical with new features in TLS, the client indicates support for the new extension in the ClientHello message. The newly introduced extensions allow remote attestation credentials and nonces to be exchanged. The nonces are used for guaranteeing freshness of the exchanged evidence when the background check model is in use.

In TLS a client has to demonstrate possession of the private key via the CertificateVerify message, when client-based authentication is requested. The attestation payload must contain assertions relating to the client's TLS Identity Key (TIK-C), which associate the private key with the attestation information. These assertions may come in the form of a Key Attestation Token (KAT), or of specific claims in an attestation result document.

In a monolithic implementation, the TLS stack is completely embedded within the TEE. In a split implementation, the TLS stack is located outside the TEE, but any private keys (and in particular, the TIK) only exist within the TEE. In order to support both options, only the TIK's identity and its public component are ever passed between the Client or Server TLS stack and its Attestation Service.

5. Use of Remote Attestation Credentials in the TLS Handshake

For both the passport model and background check model the following modes of operation are allowed when used with TLS, namely:

TLS client is the attester,
TLS server is the attester, and
TLS client and server mutually attest towards each other.

5.1. Handshake Overview

The handshake defined here is analogous to certificate-based authentication in a regular TLS handshake. Instead of the certificate's private key, we use the TIK identity key. This key is attested, with attestation being carried by the Certificate message. Following that, the peer being attested proves possession of the private key using the CertificateVerify message.

Depending on the use case, the protocol supports peer authentication using attestation only, or using both attestation and a regular public key certificate.

Not all platforms support this model, and a document that defines private key attestation for use in TLS Attestation as defined here, must specify:

The format and the lifetime of TIK (e.g. an ephemeral, per session TIK vs. a long lived one).
How the key is attested using a structure carried by the Certificate message.
How proof of possession is performed.

5.2. TLS Client Authenticating Using Evidence

In this use case, the TLS server (acting as a relying party) challenges the TLS client (as the attester) to provide evidence. The TLS server needs to provide a nonce in the EncryptedExtensions message to the TLS client so that the attestation service can feed the nonce into the generation of the evidence. The TLS server, when receiving the evidence, will have to contact the verifier (which is not shown in the diagram).

An example of this flow can be found in device onboarding where the client initiates the communication with cloud infrastructure to get credentials, firmware and other configuration data provisioned to the device. For the server to consider the device genuine it needs to present evidence.

       Client                                           Server

Key  ^ ClientHello
Exch | + evidence_proposal
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                                               v
                                        {EncryptedExtensions}  ^  Server
                                          + evidence_proposal  |  Params
                                                      (nonce)  |
                                         {CertificateRequest}  v
                                                {Certificate}  ^
                                          {CertificateVerify}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate}
Auth | {CertificateVerify}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

        Figure 1: TLS Client Providing Evidence to TLS Server.

5.3. TLS Server Authenticating Using Evidence

In this use case the TLS client challenges the TLS server to present evidence. The TLS server acts as an attester while the TLS client is the relying party. The TLS client, when receiving the evidence, will have to contact the verifier (which is not shown in the diagram).

An example of this flow can be found in confidential computing where a compute workload is only submitted to the server infrastructure once the client/user is assured that the confidential computing platform is genuine.

       Client                                           Server

Key  ^ ClientHello
Exch | + evidence_request
     |   (nonce)
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                                               v
                                        {EncryptedExtensions}  ^  Server
                                          + evidence_request   |  Params
                                                               |
                                         {CertificateRequest}  v
                                                {Certificate}  ^
                                          {CertificateVerify}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate}
Auth | {CertificateVerify}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

        Figure 2: TLS Server Providing Evidence to TLS Client.

5.4. TLS Client Authenticating Using Attestation Results

In this use case the TLS client, as the attester, provides attestation results to the TLS server. The TLS client is the attester and the the TLS server acts as a relying party. Prior to delivering its Certificate message, the client must contact the verifier (not shown in the diagram) to receive the attestation results that it will use as credentials.

       Client                                           Server

Key  ^ ClientHello
Exch | + results_proposal
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                                               v
                                        {EncryptedExtensions}  ^  Server
                                           + results_proposal  |  Params
                                         {CertificateRequest}  v
                                                {Certificate}  ^
                                          {CertificateVerify}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate}
Auth | {CertificateVerify}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

        Figure 3: TLS Client Providing Results to TLS Server.

5.5. TLS Server Authenticating Using Results

In this use case the TLS client, as the relying party, requests attestation results from the TLS server. Prior to delivering its Certificate message, the server must contact the verifier (not shown in the diagram) to receive the attestation results that it will use as credentials.

       Client                                           Server

Key  ^ ClientHello
Exch | + results_request
     | + key_share*
     | + signature_algorithms*
     v                         -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                                               v
                                        {EncryptedExtensions}  ^  Server
                                           + results_request   |  Params
                                                               |
                                         {CertificateRequest}  v
                                                {Certificate}  ^
                                          {CertificateVerify}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate}
Auth | {CertificateVerify}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

  Figure 4: TLS Server Providing Attestation Results to TLS Client.

Will be covering the Evidence Extensions in next blog post.

Credits

Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Managing the cryptographic keys within Trusted Execution Environment

Thu, 15 Feb 2024 00:00:00 GMT

The Trusted Platform Module (TPM) is a dedicated hardware component designed to enhance the security of computing systems. It provides a root of trust for the platform and offers various security-related functions. The primary role of a hardware TPM involves secure storage, key management, and attestation.

Cryptographic key management in a Trusted Execution Environment (TEE) involves the generation, storage, and usage of cryptographic keys to ensure the security of operations within the TEE.

1. Key Generation:

Flow Diagram:

+---------------------+
|  TEE Initialization |
+---------------------+
           |
           v
+---------------------+
|   Key Generation    |
|   (Asymmetric,      |
|    Symmetric, etc.)  |
+---------------------+
           |
           v
+---------------------+
|    Key Storage      |
+---------------------+

During the initialization of the TEE, cryptographic keys are generated. These keys can be either symmetric or asymmetric, depending on the specific requirements of the TEE application.
Asymmetric keys usually include a public-private key pair, while symmetric keys are a single shared secret.
After generation, the keys need to be securely stored within the TEE to prevent unauthorized access.

2. Key Storage:

Flow Diagram:

+---------------------+
|    Key Storage      |
+---------------------+
           |
           v
+---------------------+
|   Secure Storage    |
|   within the TEE    |
+---------------------+
           |
           v
+---------------------+
|   Access Controls   |
|   (Hardware-based   |
|   and Software-based|
|   protections)      |
+---------------------+

The generated cryptographic keys are stored securely within the TEE. This storage needs to be resistant to various attacks, such as side-channel attacks or unauthorized access attempts.
Access controls, both hardware-based and software-based, are implemented to restrict access to the stored keys. Only authorized processes or entities within the TEE should have access to these keys.

3. Key Usage:

Flow Diagram:

+---------------------+
|    Key Usage        |
+---------------------+
           |
           v
+---------------------+
|   Cryptographic     |
|   Operations        |
|   (Encryption,       |
|   Decryption,        |
|   Signing, etc.)     |
+---------------------+
           |
           v
+---------------------+
|   Result of         |
|   Cryptographic     |
|   Operation         |
+---------------------+

Cryptographic keys stored within the TEE are used for various operations, such as encryption, decryption, signing, or other cryptographic functions.
These operations are performed within the secure environment of the TEE, ensuring the confidentiality and integrity of the sensitive data involved.

4. Key Lifecycle Management:

Flow Diagram:

+---------------------+
|  Key Lifecycle       |
|  Management         |
+---------------------+
           |
           v
+---------------------+
|   Key Update/       |
|   Rotation          |
+---------------------+
           |
           v
+---------------------+
|   Key Revocation/   |
|   Deletion          |
+---------------------+

Key lifecycle management includes processes for key update or rotation to enhance security over time.
In case a key becomes compromised or is no longer needed, key revocation or deletion processes are implemented to ensure that the key is no longer used.
Key updates and revocations should be managed carefully to avoid disruptions to ongoing operations that rely on these keys.

In summary, cryptographic key management in a TEE involves key generation, secure storage, access controls, key usage, and key lifecycle management. These processes collectively contribute to maintaining the confidentiality and integrity of cryptographic operations within the Trusted Execution Environment.

Trusted Platform Module (TPM) as Root of Trust (rot) and cryptographic features

Thu, 08 Feb 2024 00:00:00 GMT

Root of Trust (RoT):

The Root of Trust is the foundation of a secure system, providing a starting point for establishing trust. It is typically a hardware-based component or set of components that are inherently trusted. The RoT ensures the integrity and security of a system from the beginning of the boot process.

Secure Storage:

Key Storage: TPMs are equipped with secure storage areas that protect cryptographic keys from unauthorized access. This storage is often referred to as the Platform Configuration Registers (PCRs).
Endorsement Key (EK): The TPM is initialized with a unique and secret Endorsement Key (EK) during manufacturing. The EK serves as a root key for the TPM and is used for attestation purposes.

Key Management:

Key Generation: TPMs can generate cryptographic key pairs, including public and private keys, within the hardware. These keys can be used for various security functions.
Storage Root Key (SRK): TPMs often have a Storage Root Key (SRK), which is used to protect other keys. It is a key generated within the TPM during initialization and is typically used to wrap (encrypt) and protect other keys.

Sealing and Unsealing:

Data Protection: TPMs can be used to seal (encrypt) sensitive data based on the state of the system. The data can only be unsealed (decrypted) if the system is in a specific, expected state.
Binding Keys: Public-private key pairs generated by the TPM can be used for data binding, where data is bound to a specific system state, ensuring its integrity.

Secure Boot and Measurement:

Boot Integrity: TPMs are involved in the secure boot process, measuring each stage of the boot sequence and extending the measurements into the PCRs. This provides a chain of trust from the hardware to the operating system.
Integrity Verification: The measurements recorded in the PCRs can be used to verify the integrity of the system. Deviations from the expected values indicate potential tampering.

Secure Key Exchange:

Asymmetric Key Exchange: TPMs can facilitate secure key exchange protocols by generating, storing, and managing asymmetric key pairs.
Key Wrapping: Public keys can be used to wrap (encrypt) other keys, ensuring that they can only be unwrapped (decrypted) by the TPM that generated the wrapping key.

Attestation (In detail):

The TPM attestation process provides a way to remotely verify the trustworthiness of a computing platform. It relies on the TPM's ability to securely measure the platform's state, generate signed attestation data, and allow remote entities to verify the integrity and authenticity of that data. The use of attestation enhances security in scenarios such as secure boot, remote device management, and secure communication between devices.

TPM Initialization and Key Generation:

During manufacturing, the TPM is initialized with a unique and secret Endorsement Key (EK). The EK serves as a root of trust for attestation.
The TPM can generate other keys, such as Storage Root Key (SRK) and Attestation Identity Key (AIK), during its initialization.

Measurement and PCR Extending:

During the system boot process, each component (bootloader, BIOS, OS kernel, etc.) is measured using a cryptographic hash function (e.g., SHA-256).
The measured values are extended into the Platform Configuration Registers (PCRs) of the TPM. PCRs are registers that store hash values and serve as a cumulative measure of the system's state.

AIK Creation (Optional):

The platform may create an Attestation Identity Key (AIK) within the TPM. The AIK is used for attestation and is typically bound to specific PCRs to link it to the platform's state.
The AIK is associated with the Endorsement Key (EK) and is used to sign attestation data.

Quote Generation:

The platform, or a software component within the platform, generates a quote. A quote is a signed set of PCR values from the TPM. It proves that the platform is in a specific state.
The quote is signed with the AIK, providing evidence that the attestation data comes from a TPM with a specific Endorsement Key.

Challenge-Response Protocol (Optional):

The verifier (remote entity) may challenge the platform to provide a quote. The challenge-response protocol ensures that the attestation is not replayed.
The platform generates a response to the challenge, including a new quote.

Sending Attestation Data:

The platform sends the attestation data (quote) to the verifier. This may include the PCR values, the AIK's signature, and other relevant information.
The attestation data is typically sent securely, often through a secure channel like TLS.

Verification by the Verifier:

The verifier receives the attestation data and performs the following checks:
- Signature Verification: The AIK's signature is verified using the EK's public key.
- PCR Values: The PCR values are checked to ensure they match the expected values for a trusted platform.
- Validity Check: The AIK, EK, and other elements are checked against known, trusted values.

Trust Decision:

Based on the verification results, the verifier makes a trust decision. If the attestation data is valid and matches the expected state, the platform is deemed trustworthy.
The verifier can decide whether to allow access, establish a secure communication channel, or take other actions based on trust.

In summary, the hardware TPM plays a crucial role in providing a secure foundation for computing systems. It offers secure storage for cryptographic keys, supports key generation and management, enables remote attestation, and ensures the integrity of the system through secure boot processes.

Public and private keys within the TPM are utilized for various cryptographic operations, attestation, and data protection, contributing to the overall security of the platform.

Deep dive into the Confidential Containers (CoCo)

Sun, 14 Jan 2024 00:00:00 GMT

What is Confidential Computing?

Data can exist in three states:

Data in storage is at rest.
Data traversing the network is in transit.
Data being processed is in use.

Encryption at rest

Prevents data from being obtained in an unencrypted form, in the event of an attack.
Used in services such as Disk Encryption, SQL Databases, Storage Accounts, etc.

Encryption in transit (E2E)

Prevents data from being sent in clear text over public or private networks.
Typically happens via SSL and TLS protocols.

Encryption in use

Protecting the data in use at processor/memory and caches.

Key Components

The following diagram shows how the different building blocks for Confidential Computing (CC) come together:

Infra layer

It can be on-premises (bare metal, VMware etc.) or public clouds (AWS, Azure, GCP, etc.)

Hardware with CC support - this includes 2 distinct models:

VM-based TEEs - In this model, memory is encrypted along a traditional VM boundary running on top of a VMM. AMD SEV-SNP, Intel TDX, IBM Secure Execution and Protected Execution Functionality (PEF) are examples of VM-based TEEs.
Process-based TEEs - In this model, a process that needs to run securely is divided into two components: trusted and untrusted. The trusted component resides in encrypted memory and handles confidential computing, while the untrusted component interfaces with the operating system and propagates I/O from encrypted memory to the rest of the system. Intel SGX is an example of a process-based TEE.

Hypervisor

This includes hypervisors such as QEMU/KVM, cloud hypervisor, public cloud provider hypervisors etc.

The Confidential Computing Services

This block contains a number of services (colored pink) which are required for creating a holistic CC platform which the customer can then use to build their solution. This currently includes the following services:

Attestation service - The primary purpose of the attestation service is to validate the evidence provided by the hardware TEE. This is the Verifier, as defined in the RATS architecture.

Key Broker Service (KBS) - The KBS is the Relying Party, as defined by the RATS architecture. Following are its primary functions:

Receive evidence from the Attester (confidential VM or container) via a challenge-response protocol.
Relay the evidence to the Attestation Service for verification.
Apply appraisal policy for the returned Attestation Results to assess the trustworthiness of the Attester.
Interact with the Key Management Service to retrieve the keys and then send them back to the Attester.

Key management service - A service for securely storing, managing and backing up of cryptographic keys used by applications and users.

Image build service - Services used to build confidential containers or VM images for end users.

Image registry - A service that is used to store encrypted and/or signed container and VM images required for CC workloads. Examples of such registries include Quay.io, Docker Hub, CSPs provided registries, etc.

Confidential Container Stack

The two following sections describe a generic software architecture for Kubernetes pods to run in either VM-based or process-based TEEs.

Although internal implementations for the two approaches differ, they share the same goals and attributes:

Remove cloud and infrastructure providers from the guest application Trusted Computing Base (TCB).
Integrate natively with the Kubernetes control plane.
Provide an unmodified Kubernetes user and developer experience.
Deploy unmodified workloads.

VM-based TEE

VM-based TEEs (e.g. AMD SEV, IBM SE or Intel TDX) can be used to build a confidential containers software architecture:

Following is the workflow when deploying a Kubernetes pod with VM-based TEEs:

CC workload preparation

User builds the container image(s) (e.g. with tools like podman).
User signs/encrypts the container image(s).
User pushes the container image(s) to the image registry.

Deploying the CC workload in k8s

User deploys the workload (kubectl apply -f cc_workload.yaml).
Kubernetes schedules the workload to target host having the required capability to run confidential containers.

CC workload execution flow (red connector in the diagram)

Confidential containers runtime on the host starts the VM TEE (The enclave).
Enclave (agent) performs remote attestation: steps 1-2 in the diagram.
Enclave (agent) gets the keys required to verify/decrypt the containers image(s): steps 3-4 in the diagram.
Enclave (image management) downloads the container image(s) : step 5 in the diagram.
Enclave verifies/decrypts the container image(s) : step 6 in the diagram.
Enclave starts the container workload.

Process-based TEE

The confidential containers software architecture can also be built on top of process-based TEEs like e.g. Intel SGX:

Following is the workflow when deploying a Kubernetes pod with a process-based TEEs. The main differences from the VM-based TEE approach are the last 3 steps involving interaction between 2 enclave processes:

CC workload preparation

User builds the container image(s) (e.g. with tools like podman).
User signs/encrypts the container image(s).
User pushes the container image(s) to the image registry.

Deploying the CC workload in k8s

User deploys the workload (kubectl apply -f cc_workload.yaml).
Kubernetes schedules the workload to target host having the required capability to run confidential containers.

CC workload execution flow (red connector in the diagram)

Confidential containers runtime on the host starts the enclave agent.
Enclave (agent) performs remote attestation: steps 1-2 in the diagram.
Enclave (agent) gets the keys required to verify/decrypt the containers image(s): steps 3-4 in the diagram.
Enclave (image management) downloads the container image(s) : step 5 in the diagram.
Enclave verifies, decrypts and writes the container image(s) to a local encrypted filesystem: step 6 in the diagram.
The runtime starts the app enclave which reads the container bundle from the encrypted filesystem.
Secure use of the encrypted filesystem is facilitated by a key exchange between the agent and app enclaves using either sealing or local attestation.

As can be seen, the flows for process and VM-based TEEs are almost identical. It should be noted that process-based TEE requires a few additional software components like libOS without which the application requires re-architecting. This is not the case for VM-based TEEs. Conversely, Process based TEEs do not require a separate VM and CC-aware hypervisor.

Credits

Confidential Containers

Remote Attestation Procedures Architecture (RATS) - Part-I

Fri, 17 Nov 2023 00:00:00 GMT

Introduction

The question of how one system can know that another system can be trusted has found new interest and relevance in a world where trusted computing elements are maturing in processor architectures.

Systems that have been attested and verified to be in a good state (for some value of "good") can improve overall system posture. Conversely, systems that cannot be attested and verified to be in a good state can be given reduced access or privileges, taken out of service, or otherwise flagged for repair.

For example:

A bank backend system might refuse to transact with another system that is not known to be in a good state.
A healthcare system might refuse to transmit electronic healthcare records to a system that is not known to be in a good state.

In Remote Attestation Procedures (RATS), one peer (the "Attester") produces believable information about itself - Evidence - to enable a remote peer (the "Relying Party") to decide whether to consider that Attester a trustworthy peer or not. RATS are facilitated by an additional vital party, the Verifier.

The Verifier appraises Evidence via appraisal policies and creates the Attestation Results to support Relying Parties in their decision process.

Architectural Overview

Figure 1 depicts the data that flows between different roles, independent of protocol or use case.

The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.

The Verifier role is assigned to entities that use the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester. This procedure is called the appraisal of Evidence.

Subsequently, the Verifier role generates Attestation Results for use by Relying Parties.

The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, or might be configured into the Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism.

The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions. This procedure is called the appraisal of Attestation Results.

The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be configured into the Relying Party by the Relying Party Owner, or might be programmed into the Relying Party, or might be obtained via some other mechanism.

Layered Attestation Environments

An Attester may consist of one or more nested environments (layers). The bottom layer of an Attester has an Attesting Environment that is typically designed to be immutable or difficult to modify by malicious code. In order to appraise Evidence generated by an Attester, the Verifier needs to trust various layers, including the bottom Attesting Environment. Trust in the Attester's layers, including the bottom layer.

In layered attestation, Claims can be collected from or about each layer beginning with an initial layer. The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers. Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about an initial layer typically are asserted by an Endorser.

The example device illustrated in Figure 2 includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system kernel.

The first Attesting Environment, the ROM in this example, has to ensure the integrity of the bootloader (the first Target Environment).Claims relating to the integrity of the bootloader have to be measured securely.

After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that the successfully measured bootloader now becomes (or contains) an Attesting Environment for the next layer. This procedure in layered attestation is sometimes called "staging".

It is important that the bootloader not be able to alter any Claims about itself that were collected by the BIOS. This can be ensured having those Claims be either signed by the BIOS or stored in a tamper-proof manner by the BIOS.

Continuing with this example, the bootloader's Attesting Environment is now in charge of collecting Claims about the next Target Environment, which in this example is the kernel to be booted. The final Evidence thus contains two sets of Claims:

one set about the bootloader as measured and signed by the BIOS,
a set of Claims about the kernel as measured and signed by the bootloader.

This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This would result in a third set of Claims in the Evidence pertaining to that application.

The essence of this example is a cascade of staged environments. Each environment has the responsibility of measuring the next environment before the next environment is started.

In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown by example in Figure 2.

To be continued in the next blog post

References

Remote Attestation Procedures Architecture

Protection against vulnerabilities at boot time with Linux Secure Boot Process

Wed, 15 Nov 2023 00:00:00 GMT

Computers are vulnerable during the boot process if they are not secured. The kernel, hardware peripherals and user space processes are all initiated at boot and any vulnerability in the boot firmware can have cascading effects on the entire system.

When enabled and fully configured, UEFI secure boot helps the software running on top of UEFI resist attacks and infection from malware. UEFI secure boot detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures. Detections are blocked from running before they can attack or infect the system.

UEFI secure boot works like a security gate. Code signed with valid keys (whose public key/certificates exist in the DPU) gets through the gate and executes. However, UEFI secure boot blocks at the gate and rejects a code that has a bad signature or no signature.

How it works

The boot process is authenticated by default. Authentication is based on the verification of digital signatures.

Integrity verification

The integrity of the boot firmware must be proven before trust is established in user space processes. This requires a secure mechanism to establish integrity.

Such a mechanism should be implemented into low level computer initialisation firmware like UEFI, as validating the boot process integrity at this low level assures that a device has started up in a secure state.

Standard requirements and recommendations for boot integrity measurement are following (NIST 800-155):

Enable endpoints to measure the integrity of all executables and configuration metadata at boot time
Securely transmit measurements of integrity
Provide the hardware support necessary to implement credible root of trust for integrity measurements

The root of trust is the most critical element for integrity determination. It can be implemented in hardware through secure elements or Trusted Platform Module (TPM) or coded in software using cryptographic libraries (Trusted Execution Environment).

Chain of Trust

Each component in the boot sequence cryptographically validates the authenticity of the subsequent component in the boot sequence. Every component is measured before it is loaded in the runtime memory space. If an improper or unsigned component is detected, the boot process is stopped.

Digital keys

We can use either of the hardware or software root of trust for secure boot. Security admins can create and store the digital keys used to validate the boot sequence in either a secure element, a TPM device or a software TEE

Typical Boot Process

When an Ubuntu machine boots, it goes through 4 main phases.

BIOS phase- firmware on motherboard, typically stored as a form of read only memory (ROM), contains code to initialize the hardware components of the computer and obtain the code for the bootloader.
Bootloader phase- loads the operating system into memory along with an inital ram disk filesystem (initrd).
Kernel phase- the kernel executes the init script inside the initrd filesystem. This loads hardware drivers and mounts the root partition.
System startup- the operating system loads system daemons and services, sets up the network, mounts file systems, starts system logging, and performs other initialization tasks.

It is common for a 512-bit partition to be present on Linux systems called the Master Boot Record (MBR). This partition contains the bootloader (GRUB, LILO, yaboot, or others) and boot records. This is one of the places that Linux can be booted from.

Pre-bootloader (Shim)

When enabling Secure Boot, it is important to understand shim. In the context of SecureBoot, a shim is a pre-bootloader program that is designed to work with Secure Boot firmware. It allows for bootloaders and kernel modules to be loaded and executed if they are not included in the Secure Boot database. In Ubuntu, the shim loader is pre-installed and signed by the Microsoft certificate authority.

Secure Boot uses asymmetrical cryptography, meaning that a public and private key are used. The key pair can be generated by the user and the private key is used to sign all programs that are allowed to run, including the GRUB bootloader. The firmware on the BIOS or UEFI will use the public key to verify the checksums and signatures of programs before allowing them to execute.

Boot loader

UEFI Secure Boot allows users to install their own keys and sign boot loaders themselves, and in that case the boot loader can do whatever the user is comfortable with. Typically, that means that the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel.

Kernel Signing

Intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed.

The kernel is the core code of the operating system, providing access to hardware and other services. The bootloader starts the kernel running. To keep kernels to a reasonable size and permit separate modules for separate hardware, modern kernels also use a file system which is present in memory, called an 'initrd' for 'initial ram disk'.

Both the kernel file to load and the initial ram disk are normally specified as options to the boot loader.

The kernel launches the init script inside the initrd file system, which loads hardware drivers and finds the root partition.

System startup

After the kernel is running, the remainder of the operating system is brought online.

First the root partition and filesystem is located, checked and mounted. Next the init process is started, which runs the initialization scripts. These scripts involve different /etc/rc scripts and upstart events that eventually gives you a ready-to-use computer with a login screen.

Booting components

MBR (IBM-compatible PCs)

The master boot record is the first sector on a disk and contains in general a partition table for the disk and a simple boot loader. This simple boot loader will in most cases just look for an active partition on the same disk and jump to the boot sector on that partition. The boot sector will contain the real boot loader.

GRUB Boot loader

Because the GRUB boot loader provides menus of choices and can handle many different forms of hardware, it is larger than the code which can fit in a single MBR. It has 3 stages: stage 1 in the MBR, stage 1.5 in the remainder of the first cylinder of the disk, and stage 2 within in file on the disk.

Grub will find the /boot/grub/menu.lst which configures its interactive menu. The location of the menu.lst, as well as stage1.5 and stage2 files, is hard-coded into grub when it is installed to the boot sector. Grub locates and loads the kernel and the initrd, using BIOS calls and its build-in recognition of file systems (thanks to the different available stage1.5 parts). And finally boots the kernel.

In some cases, the operating system is split over several partitions (like /usr), and these partitions are mounted by the boot scripts as soon as they can be.

Chain of Execution

First, the BIOS has to find the boot loader and this depends on your hardware's capabilities.
Second, the boot loader has to find the kernel and initrd. It will likely use BIOS calls, so this again depends on your BIOS.
Finally, the kernel will boot and must, with the help of the initrd, find the root partition

root partition

The root partition with the operating system can be somewhere completely different than the kernel, for instance on another drive or on a remote computer. In some cases the kernel may not find the root partition on the disk, because the initrd is missing the modules to access the partition. If this your case, rebuild your initrd to include the missing modules (see man mkinitramfs and man update-initramfs).

References

Bits and pieces of confidential virtual machine architecture

Sat, 04 Nov 2023 00:00:00 GMT

Confidential Computing enhances the security of public cloud platforms by adopting a nuanced approach rather than an all-or-nothing strategy. It minimizes the vulnerability of a cloud environment through the implementation of a defense-in-depth architecture.

This is accomplished by leveraging security technologies embedded in central processing units (CPUs), including the AMD SEV technology, Trusted Platform Modules (TPMs), and the built-in security features of operating systems like Ubuntu. Now, let's explore how these protective measures are implemented within the cloud environment using Ubuntu.

Runtime VM Memory Encryption

Confidential VMs are powered by AMD's SEV technology, which encompasses SEV, SEV-ES, and SEV-SNP. These VMs operate within a secure environment, employing AES encryption to safeguard their memory and CPU registers. This robust encryption guarantees that neither other VMs nor the host administrator can access the data being processed. The operational concept can be visualized in the simplified diagram below.

While the CPU is in the guest VM mode, it consistently encrypts the memory locations it writes to and decrypts them when reading. Each VM is allocated specific memory areas, ensuring that in the event of a hypervisor breach, one VM cannot access the memory of another VM; it can only access an encrypted version of it.

This model empowers the creation of private VMs within the public cloud, making them suitable for handling sensitive workloads. However, it's important to note that this represents just one aspect of cloud security. While runtime memory encryption plays a vital role in this security framework, workloads running in the cloud are typically loaded from the cloud's infrastructure, often from a hard disk.

VM Encryption at rest

Ubuntu's operating system takes care of safeguarding data while it's at rest. Through its robust full disk encryption capabilities, Ubuntu guarantees that all data written to the disk is encrypted and decrypted using AES. Additionally, it ensures the validation of each boot step through the UEFI secure boot process. The key necessary for disk encryption is securely stored within the virtual disk in an encrypted format.

The guest operating system is also responsible for providing greater security to the data at rest. As access to storage volumes is normally arbitrated by the host, the only feasible way for delivering confidentiality is encryption.

Opting for full disk encryption, rather than encrypting specific data volumes, appears to be an attractive approach. However, a key consideration arises: Is it feasible to encrypt every element comprehensively? Given that we cannot depend on the host to handle decryption on our behalf, it necessitates retaining some decryption code in an unencrypted form.

Key to decrypt the encrypted part of the storage volume must be automatically accessible to the genuine VM but to no one else. The most common way this is currently achieved is by using a virtual Trusted Platform Module (vTPM) backed by hardware.

While it doesn’t seem to be possible to hide it, the true requirement is to make sure the untrusted host cannot modify it unnoticed. To achieve that, code signing technologies like UEFI SecureBoot can be utilized. SecureBoot is a technology which guarantees that only the code trusted by the platform vendor is executed when the system boots, allowing it to prevent attacks on the system before the operating system is fully loaded.

VM Encryption during boot time

With confidential disk encryption, the root volume of a VM is pre-encrypted prior to the first boot on the target host. Some parts of the volume must remain unencrypted. In particular, all the code required to obtain the key to the encrypted part of the volume and perform the decryption must remain as cleartext.

When the root volume of the operating system is encrypted, the decryption must happen in the initramfs; meaning that the bare minimum unencrypted volume must include all pieces of the boot chain up to the initramfs:

The key to the encrypted part needs to be revealed during the initramfs boot phase so the boot sequence can continue to the operating system. This also means that all the code running in the VM up to that point must be verified to prevent a possible attack from a compromised host trying to reveal the encryption key. For example, if the initramfs is not verified, then the host can try injecting some malicious code into it to steal the key.

The established standard for boot time code verification is UEFI SecureBoot, which guarantees that only code trusted by the platform vendor is executed when the system boots. Traditionally, SecureBoot scheme covers the following:

First stage bootloader (shim)
Second stage bootloader (GNU GRUB)
Linux kernel

The vTPM operates within the Guest VM address space, so it is protected by the run-time memory encryption of the CPU, and is also encrypted at rest.

References

Zero Trust Architecture and Confidential Computing

Sun, 29 Oct 2023 00:00:00 GMT

Historically, safeguarding corporate assets relied on perimeter-based security measures, with a clear division between trusted users and data on the inside and potential threats on the outside. However, as the world evolved, remote work became the norm, and individuals began connecting to their corporate networks from various locations, including their homes or while traveling.

Additionally, the rise of cloud computing enabled data and workloads to migrate outside the traditional data center. As a result, the conventional security perimeter became obsolete. In response to this shifting landscape, a new approach was needed, giving rise to the concept of Zero Trust.

What Exactly is Zero Trust?

The most authoritative source on the subject is NIST Special Publication 800-207, titled "Zero Trust Architecture." According to this publication, zero trust revolves around the idea of managing identity and access to resources within an enterprise network.

The fundamental principle is that no entity should be automatically trusted solely because it belongs to a particular network or is located in a specific physical location. In essence, zero trust involves assuming that a breach of the enterprise network has already occurred. In line with this perspective, NIST identifies encrypting all network traffic and implementing session-based access control for network resources as key pillars of the "basic tenets" of zero trust.

This stands in contrast to traditional security models where everything within the enterprise network is inherently trusted, while everything outside is not. In such a traditional model, once attackers breach the network, such as bypassing the firewall, they gain access to all resources on the enterprise network.

How Does Confidential Computing Enhance Zero Trust?

Confidential computing enhances Zero Trust by providing a secure execution environment for sensitive workloads, even in untrusted environments. Zero Trust calls for constant verification of all resource access but ensuring that the underlying cloud infrastructure is reliable and secure might be challenging.

The hardware-based security mechanism offered by confidential computing solves this problem by enabling the processing and storage of sensitive data in a safe enclave isolated from the host system and other potentially vulnerable components.

Confidential Computing is the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment.

Confidential Computing Consortium, https://confidentialcomputing.io/about/

Confidential Computing, as thus described, can provide two properties which are excellent starting points for components wishing to exercise zero/explicit trust, which we’ll examine individually:

Isolation from the host machine/system, particularly in terms of confidentiality of data at runtime
Cryptographically verifiable identity.

Runtime Encryption

One of the primary trust considerations for any executing component is the relationship it establishes with the system providing its execution capabilities, typically the host machine. Even when a component claims to have "zero trust," it must still trust the host machine to maintain the confidentiality of its code and data. This reliance on the host machine and its administrators, including potential compromises, does introduce a substantial trust relationship. This situation seems incompatible with the concept of a "zero trust" architecture, but there are potential solutions.

Confidential Computing offers a solution by enabling isolation from the host machine responsible for execution. While the component still needs to trust the CPU and firmware facilitating the execution context (because code must run, after all), this approach significantly reduces the number of trust relationships required. It also allows for cryptographic assurances to underpin this relationship, as outlined in the "Attestation" section.

The assurance that a component is isolated from other components provides several benefits. It allows the component to have confidence in its operation, knowing it can function independently. It also enables other components to establish trust relationships with it, with the assurance that it acts autonomously and is not under the influence of a malicious actor.

Cryptographic Attestation

As mentioned earlier, zero trust emphasizes the importance of verifying the identities of entities on a network and implementing access control based on sessions and resources. Without hardware-based remote attestation, access control primarily relies on cryptographic keys held by these entities, such as applications, services, or end-user devices, and unverifiable reports regarding aspects like patch levels. In this setup, if, for instance, the private key of a service gets compromised, an attacker can effectively impersonate that service.

This is where confidential computing-style remote attestation makes a significant difference. It enables software to prove their precise identity and integrity to a verifier, which plays a crucial role in access control. Specifically, the verifier gains clear insights into the cryptographic hash of the software, the confidential computing features it utilizes (such as runtime encryption), and its public key. To forge this information, an attacker would need to compromise the remote attestation protocol of the confidential computing technology in use, such as Intel SGX or AMD SEV. While not impossible, this is a formidable challenge, beyond the capabilities of most attackers.

In light of this, it's reasonable to assert that confidential computing-style remote attestation brings a substantial enhancement to the verification aspect of zero trust. It shifts us from predominantly relying on certificate-based identities (which are susceptible to theft) to dynamically attested, semantics-based identities, offering a more robust foundation for trust and security.

Forging a "Zero Trust" Connection

These attributes enable the formation of zero (or "explicit") trust connections with components operating within a Confidential Computing environment. This approach is a departure from traditional computing methods where any component's trust relationship is inherently tied to the environment in which it operates, typically the system providing its execution environment. Such a relationship is far from being a zero trust model and is often far from explicit.

In a Confidential Computing environment, components can establish only a limited set of explicitly defined trust relationships, typically including the attestation service, the CPU/firmware provider, and the provider of the executing code. This results in a significantly more well-defined trust framework. While it may not achieve a perfect "zero trust" state, it at least moves closer to the concept of "minimal trust."

AMD Secure Encrypted Virtualization (SEV) on AMD EPYC™ Microprocessors

Sat, 21 Oct 2023 00:00:00 GMT

Confidential Compute on AMD

Confidential computing helps keep data private while it’s in use. In the past, data remained undefended while it was being processed virtually or in the cloud. Confidential computing on AMD EPYC™ processors can be enabled using built-in security features like Secure Encrypted Virtualization (SEV), Secure Memory Encryption (SME) which helps protect data in use.

AMD's memory encryption technologies that are designed to address these needs across a variety of systems and can be broadly divided into several categories

Secure Memory Encryption (SME)

defines a simple and efficient architectural capability for main memory encryption.
SME is a general purpose mechanism that is flexible, integrated into the CPU architecture.
Scalable from embedded to high-end server workloads, and requires no application software modifications.

Secure Encrypted Virtualization (SEV)

Integrates main memory encryption capabilities with the existing AMD-V virtualization architecture to support encrypted virtual machines.
Encrypting virtual machines can help protect them not only from physical threats but also from other virtual machines or even the hypervisor itself.
SEV represents security paradigm to cloud computing where virtual machines need not fully trust the hypervisor and host system.
As with SME, no application software modifications are required to support SEV.

AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES)

Encrypts all CPU register contents when a VM stops running.
Prevents the leakage of information in CPU registers to components like the hypervisor.
It can even detect malicious modifications to a CPU register state.

AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP)

Adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping.
Also, SEV-SNP introduces several additional optional security enhancements designed to support additional VM use models,
It offers stronger protection around interrupt behavior, and offer increased protection against recently disclosed side channel attacks.

SEV-SNP Memory Management

SEV-SNP allows a guest to separate its memory into shared and private memory. Shared memory is accessible to host software and is marked as hypervisor-owned in the Reverse Map Table (RMP), a data structure that stores the SEV-SNP security attributes of each page of memory in the system.

Private memory is assigned to the guest in the RMP, writeable only by the guest, and encrypted with the guest’s unique memory encryption keys. The guest uses private memory to store sensitive data and its executable code. The CPU and IOMMU both enforce the access control policy for guest private memory by checking the RMP as required during address translation to ensure that the software or device accessing memory has sufficient privileges.

This comes with limitations as the device can only operate within the shared memory space of the guest and cannot access the private memory of the guest. If the guest needs data to flow between its private memory and the assigned device, the guest must copy the data in and out of a shared buffer that is accessible by both the guest and assigned devices.

Figure 1: Diagram depicting bounce buffering required for a non-trusted device (left) and direct access to private memory by a trusted device (right).

SEV Security Model

Traditional computing systems have operated using a ring-based security model. In this model, high privilege code has full access to the resources at its level and of all lower privileged levels.

In the SEV model, code executing at different levels (namely hypervisor vs guest) is isolated so neither has access to the resources of the other. Even though the hypervisor level is traditionally “more privileged” than the guest level, SEV separates these levels through cryptographic isolation. Communication between hypervisor and guest is still possible, but those communication paths are tightly controlled.

Consequently, SEV technology is built around a threat model where an attacker is assumed to have access to not only execute user level privileged code on the target machine, but can potentially execute malware at the higher privileged hypervisor level as well. The attacker may also have physical access to the machine including to the DRAM chips themselves.

In all these cases, SEV provides additional assurances to help protect the guest virtual machine code and data from the attacker. Note that SEV does not protect against denial-of-service attacks against the guest.

Figure 2: SEV Security Model

SEV Architecture

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner.

While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

Each VM as well as the hypervisor is associated with a tag, and consequently an associated encryption key. Because of the tag and memory encryption, data is restricted to only the VM using that tag. If that data is accessed by anyone else, including the hypervisor, they will only be able to see the data in its encrypted form. This provides strong cryptographic isolation between the VMs, as well as between the VMs and the hypervisor.

Figure 3: SEV Architecture

Memory Encryption

One of the key features of SEV is that guest VMs are able to choose which data memory pages they would like to be private. This choice is done using the standard CPU page tables, and is fully controlled by the guest. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with the hypervisor key.

This feature allows VMs to mark selected pages of memory data they want to keep confidential (private), and others to be used for communication with other VMs or the hypervisor. In a typical arrangement, the guest would map all of its code and data as private, except for specific shared pages that it chooses to expose.

For security, SEV hardware does require certain types of memory (including instruction pages and page tables) to always be private to protect the VM. An example communication configuration is shown in Figure 4. In this example, the SEV-enabled guest and hypervisor communicate through memory that both entities mark as shared. All other guest memory is encrypted with the guest’s key (which the HV cannot use).

Figure 4: Guest/HV Communication Example

Confidential Compute Architecture(CCA) on Armv9.2+ Microprocessors

Sun, 15 Oct 2023 00:00:00 GMT

Confidential Compute in Arm

Arm's Confidential Compute Architecture (CCA) leverages the groundwork established by Arm's TrustZone technology. Under the CCA framework, it's specifically engineered to safeguard application data, even when it's actively utilized. This level of protection extends to shielding private data from unauthorized access, even by privileged software components like the hypervisor or the operating system.

Confidential Compute Architecture is an integral part of the freshly introduced Armv9 architecture. More precisely, it serves as an optional feature within Armv9.2 and is poised to evolve into a mandatory extension in forthcoming specifications. To determine whether a CPU supports CCA, software developers can examine the presence of the Realm Management Extension (RME) feature.

Figure 1: Confidential computing features on ARM chips

Overview of Arm CCA

Previously, access to high-trust environments was primarily restricted to silicon vendors and OEMs, typically achieved through technologies like TrustZones. With the introduction of Arm CCA, the goal is to expand the availability of high-trust environments to all developers, with the aim of making it a standard for mainstream workloads. Initially, this will be implemented through OS-related software.

At the core of the Confidential Compute Architecture are "Realms," which function as small, self-contained high-trust environments or enclaves. The architecture is specifically engineered to safeguard private data throughout the entire technology stack, starting from the silicon level.

CCA offers robust protection for isolating workloads that inherently distrust each other, providing resilience against compromised rich operating systems such as Linux or Windows, fortifying defenses against compromised hypervisors, and introducing novel protection measures for applications operating within secure environments.

A significant aspect of CCA involves shielding realms from the underlying hypervisor. While the hypervisor retains responsibilities for resource allocation and tasks like scheduling, it is no longer granted access to the data contained within a realm.

The number of realms supported by a system is theoretically limitless, constrained only by the available system resources, such as memory and computational power. For instance, small IoT devices may have only a handful of realms, while a powerful server System on Chip (SoC) could handle hundreds of realms. The creation and termination of realms are designed to be efficient operations, suitable for use by applications as needed.

Figure 2: ARM Confidential Computing features on Chip

Arm CCA hardware architecture

Hardware that supports the confidential compute architecture will have the Realm Management Extension (RME) available. At its core, processors that implement the Realm Management Extension have two new hardware capabilities: the creation of realms and dynamic memory assignment.

With the new Realm Management Extension, pages can now transition from the non-secure world to the secure world and back again. This allows TrustZone to be utilized for much more memory-intensive applications.

Two new hardware features in the Realm Management Extension (RME)

1. New isolation boundaries for 3rd party confidential computing

Realms: New type of protected execution environment
Data and/or code are protected from any other execution environments:
- Hypervisors
- OS Kernels
- Other Realms
- Even TrustZone

2. Dynamic assignment of memory to physical address spaces / worlds

Supports Realms AND adds dynamic memory support to TrustZone
- Arm dynamic TrustZone technology
- Removes boot-time static memory carve-outs

RME adds another two security states and associated physical address spaces

Realm: A new mutually distrusting space for confidential compute
Root: The Monitor gets its own private address space

HW isolation between address spaces is managed through a new Granule Protection Table (GPT), an extension of MMU page tables that is controlled by the Monitor in EL3

Invalid accesses raise page faults

Figure 3: ARM Confidential Computing Arch H/W stack

CCA is a combination of hardware and firmware

As part of the Arm CCA, a new firmware/software architecture is also defined. A new Realm Management Monitor (RMM) is defined which provides services for the hypervisor as well as to the realms themselves. This is done via a new Realm Management Interface (RMI).

Figure 4: Realm Management Interface (RMI)

Services for the hypervisor include the creation and destruction of realms as well as adding and removing memory. Additionally, realms can also request attestation reports via the RMI which can be for the platform or the realm which can be presented to a requesting party.

Confidential Computing on Intel Microprocessors

Tue, 10 Oct 2023 00:00:00 GMT

What is Confidential Computing?

Data can exist in three states:

Data in storage is at rest.
Data traversing the network is in transit.
Data being processed is in use.

Encryption at rest

Prevents data from being obtained in an unencrypted form, in the event of an attack.
Used in services such as Disk Encryption, SQL Databases, Storage Accounts, etc.

Encryption in transit (E2E)

Prevents data from being sent in clear text over public or private networks.
Typically happens via SSL and TLS protocols.

Encryption in use

Protecting the data in use at processor/memory and caches.

Classical mechanisms to protect data in transit and at rest remain must-haves. These mechanisms are not enough when you are processing the very sensitive data. Even when you’re diligently keeping your environments up-to-date with all of the latest governance and security recommendations that Microsoft has on offer, protecting sensitive data while it is being processed might still be worth considering.

📖 From the docs: “The trusted computing base (TCB) refers to all of a system’s hardware, firmware, and software components that provide a secure environment. The components inside the TCB are considered “critical”. If one component inside the TCB is compromised, the entire system’s security may be jeopardized. A lower TCB means higher security.”

A Trusted Execution Environment (TEE), such as an Enclave/TDX, is a tampering resistant environment that provides security assurances to us. The range of assurances often depends on what ships with the TEE, but at a minimum, we will often see the following types of security assurances:

Data integrity

Prevents unauthorized entities from modifying data inside of an enclave.

Code integrity

Prevents unauthorized entities from modifying code inside of an enclave.

Data confidentiality

Prevents unauthorized entities from viewing data as it is being processed inside of an enclave.

💡 “Keep the attack surface small!” Hardware-based TEEs can remove the operating system, (cloud) platform and service providers, along with their administrators, from the list of parties that your company places trust in. Doing so can potentially reduce the risk of a security breach or compromise.

The more code that is put inside of the trusted execution environment, the more vulnerable your setup might become due to the larger trusted computing base. Again, code that is run inside of an enclave cannot be viewed by a host or hypervisor, so keeping the code-base that runs inside the TEE to a minimum will typically result in more confidentiality assurances.

Figure 1: Simplified comparison of the trusted computing base (TCB) of the different confidential computing technologies. “Infra- structure employees” includes cloud provider and datacenter employees. For Intel SGX and CVMs, the CPU enforces the secure execution context. It is thus marked with lighter purple.

With Intel based Microprocessors you can have two different type trusted computing base (TCB) environments

Intel® SGX
Intel® TDX

Intel Software Guard Extensions (SGX)

Intel® Software Guard Extensions (Intel® SGX) offers hardware-based memory encryption that isolates specific application code and data in memory. Intel® SGX allows user-level code to allocate private regions of memory, called enclaves, which are designed to be protected from processes running at higher privilege levels. Only Intel® SGX offers such a granular level of control and protection

Traditionally, when a system’s BIOS, hypervisor, or operating system is compromised by a malicious attack, the attacker’s code can gain visibility and access to everything higher in the system stack, such as applications and data. Intel SGX utilizes memory encryption and hardware-enforced access controls to change how data is accessed, providing enclaves of protected memory in which to run applications and data.

Intel SGX (Software Guard Extension) is a new instruction set in Skylake Intel CPUs since autumn 2015. It provides a reverse sandbox that protects enclaves from:

OS or hypervisor
BIOS, firmware, drivers
System management module (Ring 2)
Intel management engine (ME)
Any remote attack

In short, SGX architecture is a hardware-enforced security mechanism that requires Trusted Computing Base (TCB), Hardware Secrets, Remote Attestation, Sealed Storage and Memory Encryption.

In summary, Intel SGX offers the following protections from known hardware and software attacks:

Enclave memory cannot be read or written from outside the enclave regardless of the current privilege level and CPU mode.
Production enclaves cannot be debugged by software or hardware debuggers.
The enclave environment cannot be entered through classic function calls, jumps, register manipulation, or stack manipulation. The only way to call an enclave function is through a new instruction that performs several protection checks.
Enclave memory is encrypted using industry-standard encryption algorithms with replay protection. Tapping the memory or connecting the DRAM modules to another system will yield only encrypted data.
The memory encryption key randomly changes every power cycle. The key is stored within the CPU and is not accessible.
Data isolated within enclaves can only be accessed by code that shares the enclave.

As a result, the attack surface can be largely reduced after applying Intel SGX:

Figure 2: Attack Surface

Intel Trust Domain Extensions (TDX)

This hardware-based trusted execution environment (TEE) facilitates the deployment of trust domains (TD), which are hardware-isolated virtual machines (VM) designed to protect sensitive data and applications from unauthorized access.

A CPU-measured Intel TDX module enables Intel TDX. This software module runs in a new CPU Secure Arbitration Mode (SEAM) as a peer virtual machine manager (VMM), and supports TD entry and exit using the existing virtualization infrastructure. The module is hosted in a reserved memory space identified by the SEAM Range Register (SEAMRR).

Intel TDX uses hardware extensions for managing and encrypting memory and protects both the confidentiality and integrity of the TD CPU state from non-SEAM mode.

The main security goal of Intel® Trust Domain Extension (Intel® TDX) technology is to remove the need for a TDX guest to trust the host and virtual machine manager (VMM). It is important to note that this security objective is not unique to the TDX architecture, but it is common across all confidential cloud computing solutions (CCC) (such as TDX, AMD SEV, etc) and therefore many aspects described below will be applicable to other CCC technologies.

Figure 3 shows the Trusted Computing Base (TCB) for the Linux TDX SW stack

TDX Memory Protection - TDX leverages VMX to enforce the memory isolation for TDs. Similar to legacy VMs, TDs are unable to access the memory of other security domains. As SMM, hypervisors, the TDX Module, and other VMs/TDs. With VMX, hypervisors maintain EPTs to enforce memory isolation.

Since hypervisors are no longer trusted, TDX has moved the task of memory management to the TDX Module, which controls the address translation of TD’s private memory.

Related Posts