Protecting data vs systems: practicality, performance, and problems...

Protecting data vs systems: practicality, performance, and problems...

Speakers: Dan Draper

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=zjI1qLakD-E

Overview

This talk, presented by Dan Draper, Founder and CEO at CyStash, delves into the critical distinction between protecting systems and protecting data directly. Draper argues that traditional security approaches, which focus on applying controls to systems like databases, are inherently limited. These controls are often system-specific, operationally inefficient, and fail to protect data once it moves or is exfiltrated from its original context. The core premise of the presentation is to explore how encryption can be leveraged as a universal, granular, and deny-by-default mechanism to protect individual data values, regardless of their location or the system they reside in.

The presentation outlines a sophisticated approach combining AES GCM encryption with envelope encryption and key commitment to establish a centralized, attribute-based access control system. This system ensures that data keys are only revealed when specific contextual conditions are met, effectively turning encryption into a policy enforcement tool. A significant portion of the talk addresses the challenge of querying encrypted data, contrasting the impracticality of homomorphic encryption with the emerging viability of searchable encryption schemes like Order-Revealing Encryption (ORE), which offer practical performance for real-time database operations.

Draper's insights are crucial for security professionals grappling with the complexities of data protection in modern, distributed environments. By shifting the focus from system boundaries to the data itself, this approach promises a more robust and scalable security posture, mitigating risks associated with data breaches, Shadow IT, and the inherent limitations of disparate system-level controls. The talk provides a technical deep dive into the cryptographic primitives and architectural considerations necessary to achieve this paradigm shift, offering a compelling vision for the future of data security.

Background

▶ Watch: System-level controls fail to protect data universally. (1:00)

The pervasive challenge in data security stems from the traditional focus on protecting systems rather than the data itself. When security controls are applied to a database, for instance, they are effective only within the confines of that specific system. Should data migrate to a data warehouse, a different application, or even be copied to a local machine, the original controls become irrelevant. This leads to a fragmented and inefficient security landscape where policies must be independently configured and maintained across numerous, often heterogeneous, systems. This operational overhead is significant, increasing the risk of misconfiguration, oversight, and the emergence of "Shadow IT" where data exists in unprotected environments. Furthermore, in the event of a data exfiltration or breach, system-level controls offer no protection for the data once it leaves the controlled environment.

Prior art in access control systems, while foundational, exhibits significant limitations in achieving universal data protection. File system permissions, common in Linux or macOS, allow for owner and group-based access but are tied to the file system itself. Row-level security (RLS) in transactional databases like PostgreSQL or MySQL aims to restrict data access at a granular level. However, as Draper notes, RLS is notoriously difficult to implement correctly, is tedious, fiddly, and varies significantly in syntax and capability across different database platforms. A major impediment to RLS in modern applications is the disconnect between application identity and end-user identity; databases often only perceive the application as the "user," making fine-grained, end-user-specific RLS impractical without complex workarounds.

Similarly, Identity and Access Management (IAM) systems, prevalent in cloud environments like AWS, Azure, and Google Cloud, provide powerful mechanisms for controlling access to resources. While effective, IAM policies are also resource-centric and cloud-provider specific. Managing a multitude of IAM policies across different cloud providers and on-premises systems becomes an arduous task, leading to operational inefficiency and the risk of policy drift. The fundamental problem remains: these controls are bound to the system or resource, not the data value itself. This necessitates a paradigm shift towards protecting data directly, ensuring that its inherent security travels with it, irrespective of its location or the system interacting with it.

Key Findings

▶ Watch: Proposal: Direct data protection via cell-level encryption. (5:00)

The central finding of this presentation is that encryption can be effectively used to protect data directly, enabling a universal, granular, and deny-by-default access control mechanism that transcends system boundaries. This approach addresses the inherent limitations of traditional system-centric security controls.

Key findings and contributions include:

• Universal Data Protection through Encryption: By encrypting every individual data field (or "cell") within a database, data gains inherent protection. This means that even if data is exfiltrated or accessed from an unprotected system, it remains unintelligible without the corresponding decryption keys.
• Leveraging AES GCM with Authenticated Associated Data (AAD): The talk highlights AES GCM (Galois/Counter Mode) as the preferred encryption mode due to its authentication capabilities. Crucially, the use of AAD allows for the binding of non-sensitive contextual information (e.g., "this is an SSN") to the ciphertext. This AAD is required for successful decryption, providing an additional layer of integrity and control.
• Envelope Encryption for Key Management: The complexity of managing unique encryption keys for every data element is solved through envelope encryption. This technique uses a Key Management Service (KMS) to generate and encrypt (wrap) unique data keys with a master key. The wrapped data key can then be stored alongside the encrypted data, simplifying key distribution and management while maintaining a strong separation of concerns.
• Key Commitment for Policy Enforcement: By combining envelope encryption with AAD, the concept of key commitment emerges. When a data key is requested from the KMS, specific context (e.g., record_id=1, field_name=name) is included in the AAD used to wrap the data key. This means the data key can only be unwrapped and used if the exact same context is provided during decryption, effectively embedding policy into the key itself.
• Centralized, Attribute-Based Access Control: The key commitment mechanism, when integrated with a web-based key service, transforms into a powerful, centralized, attribute-based access control (ABAC) system. The key service can evaluate authorization tokens (like JWTs) against an internal Access Control List (ACL) based on the requested context (record ID, field name). If authorized, the unwrapped data key is returned; otherwise, access is denied (e.g., a 401 response). This provides a universal interface for permission checks, independent of the underlying data store.
• Impracticality of Homomorphic Encryption for Real-time Queries: While homomorphic encryption (FHE) allows computations on encrypted data, the talk demonstrates its severe performance limitations. Benchmarks using the thfs Rust library show a single "more than" comparison taking 191 milliseconds. This translates to unacceptably long query times (e.g., 5.5 hours for a sequential scan on 100,000 records), rendering FHE unsuitable for real-time database querying.
• Viability of Searchable/Functional Encryption (ORE): A significant finding is the emergence of practical searchable encryption schemes, specifically Order-Revealing Encryption (ORE). ORE allows for efficient comparisons (more than, less than, equal to) on encrypted data. Benchmarks show ORE performing a 64-bit integer comparison in approximately 200 nanoseconds, which is 800,000 times faster than FHE. This makes real-time queries over encrypted data feasible (e.g., a sequential scan on 100,000 records taking 24 milliseconds), provided a key is used to perform the query to mitigate inference attacks.
• Architectural Flexibility: The universal interface for decryption allows for flexible deployment options, including decryption in the browser, edge workers, application layer, or database proxies, opening up new architectural patterns for data security.

These findings collectively present a compelling argument for a data-centric security model, offering a robust solution to many of the challenges faced by traditional system-level protection strategies.

Technical Deep Dive

▶ Watch: Key Commitment for context-aware, policy-driven data keys. (11:00)

The core of Dan Draper's proposed solution lies in a sophisticated combination of cryptographic primitives and architectural patterns designed to protect data directly, rather than relying solely on system-level controls.

AES GCM Encryption Primer

The foundation of the data protection scheme is AES GCM (Advanced Encryption Standard in Galois/Counter Mode). AES GCM is a widely adopted, NIST-ratified authenticated encryption mode.

The encryption process involves:

1. An Initialization Vector (IV): A unique, typically 12-byte, random value used for each encryption operation to ensure that identical plaintexts produce different ciphertexts.
2. Plaintext: The actual data to be encrypted (e.g., "love coffee", 10 bytes).
3. Key: A secret cryptographic key (e.g., a 32-byte key for AES-256).

These three inputs are fed into the AES GCM encryption function, which outputs:

1. Ciphertext (C): The encrypted form of the plaintext, which in GCM mode is the same length as the plaintext.
2. Tag: A Message Authentication Code (MAC), often referred to as a "cryptographic hash" in a simplified sense, that proves the authenticity and integrity of the ciphertext. It ensures the message hasn't been tampered with.

The IV, ciphertext, and tag are stored together. Decryption is the inverse process: providing the IV, ciphertext, tag, and the correct key to the decryption function yields the original plaintext, provided the tag verifies successfully.

A crucial feature of AES GCM is Authenticated Associated Data (AAD). This allows additional, non-sensitive information to be included in the computation of the tag. While the AAD itself is not encrypted, its authenticity is guaranteed by the tag. Critically, the exact same AAD used during encryption must be provided during decryption for the tag verification to succeed. If an incorrect AAD is supplied, decryption will fail. This property is fundamental to the concept of key commitment. For example, if encrypting a Social Security Number (SSN), the string "SSN" could be used as AAD, ensuring that the decryption process explicitly acknowledges the data type.

Envelope Encryption and Key Commitment

Managing a unique key for every encrypted data field would be a significant operational burden. This is where envelope encryption comes into play, often facilitated by a Key Management Service (KMS) (e.g., Amazon KMS, Azure Key Vault, CyStash KMS).

1. Data Key Generation and Wrapping: When a client needs to encrypt data, it requests a data key from the KMS. The KMS, using its internal, highly secure managed key (often stored in an Hardware Security Module or HSM), generates a random data key and a random IV. It then uses its managed key to encrypt (wrap) this data key. The output is a wrapped data key (which is essentially an AES GCM ciphertext of the data key) and the original, unwrapped data key. The unwrapped data key is used by the client to encrypt the actual data, and then discarded. The wrapped data key is stored alongside the encrypted data.
2. Data Key Unwrapping: To decrypt data, the client sends the wrapped data key to the KMS. The KMS uses its managed key to decrypt (unwrap) the data key, returning the unwrapped data key to the client, which then uses it to decrypt the actual data. This establishes a separation of concerns: the KMS manages the master keys and the wrapping/unwrapping process, while the client handles the actual data encryption/decryption with ephemeral data keys.

Key commitment extends envelope encryption by integrating the AAD concept. When requesting a data key from the KMS, the client includes specific context (e.g., record_id=1, field_name=name). The KMS then uses this context as AAD when wrapping the data key. The result is a wrapped and committed data key. This means that for the data key to be successfully unwrapped, the exact same context (AAD) must be provided to the KMS. If the context is incorrect or missing, the data key decryption will fail, and the client will not receive the unwrapped data key. This mechanism effectively ties the data key's usability to specific contextual attributes.

Access Control using Selective Data Key Decryption

This framework transforms into a powerful access control system. The KMS, now acting as a policy enforcement point, becomes a web service.

1. Authorization Request: A client (e.g., an application or a browser) sends an authorization token (like a JWT) and a JSON payload containing the desired context (e.g., record_id, field_name) to the key service.
2. Policy Evaluation: The key service, using an internal Access Control List (ACL) or policy engine, evaluates whether the principal identified by the JWT is authorized to access the data associated with the provided context.
3. Conditional Data Key Release:

• If the principal is not authorized, or if the provided context does not match the committed context, the key service returns a denial (e.g., HTTP 401 Unauthorized). The data key is not unwrapped or released.
• If the principal is authorized and the context is correct, the key service unwraps the data key and returns it (e.g., HTTP 200 OK) to the client. The client then uses this data key to decrypt the actual data.

This architecture offers several advantages:

• Centralized Policy Management: All access decisions are made by the key service, providing a single point of control.
• Universal Interface: A consistent API for permission checks, regardless of the underlying data storage system.
• Separation of Concerns: The key service never sees the plaintext data, only the wrapped data keys and context.
• Enhanced Logging: The key service can reliably log successful data key retrievals, providing a strong audit trail of data access. A data key will not be returned if the log cannot be written, ensuring a high level of guarantee.
• Deny-by-Default: Since data is encrypted, any unauthorized access attempt or unsupported system will only reveal ciphertext, effectively denying access to the plaintext.

The decryption process can occur in various locations:

• Browser: For client-side applications, allowing data to remain encrypted until it reaches the end-user's device.
• Edge Worker: In environments like Cloudflare or Fastly, providing decryption close to the user.
• Application: Traditional application-level encryption.
• Database Proxy: A transparent proxy sitting in front of the database, handling encryption/decryption operations.

Querying Encrypted Data: The Homomorphic vs. Searchable Encryption Dilemma

A significant challenge arises when data is fully encrypted: how to perform database queries like searches, range comparisons (e.g., date_of_birth > '2000-01-01'), or sorting?

Homomorphic Encryption (FHE) allows computations directly on encrypted data without decrypting it. While theoretically powerful, its practical performance is a major hurdle. Draper presents benchmarks using the thfs Rust library for a modern FHE scheme:

• A single "more than" comparison takes an average of 191 milliseconds.
• For a table with 100,000 records:
• If an index is used, a query like date_of_birth > '2000-01-01' might take around 3 seconds.
• If a sequential scan is required (no index or complex conditions), the same query would take 5.5 hours.

This renders FHE impractical for real-time database queries. Furthermore, FHE schemes often introduce "noise" that requires periodic bootstrapping, adding to their complexity.

The solution lies in Searchable Encryption (or Functional Encryption) schemes, specifically Order-Revealing Encryption (ORE). ORE is designed to perform specific operations, such as comparisons (more than, less than, equal to), on encrypted data efficiently.

• Benchmarks for ORE show a comparison between two 64-bit integers in Rust taking approximately 200 nanoseconds. This is 800,000 times faster than FHE.
• For the same 100,000-record table:
• A query using an index would take about 4 microseconds.
• A sequential scan would take approximately 24 milliseconds.

This performance makes ORE a practical mechanism for querying encrypted data in real-time database scenarios.

Draper notes that ORE, particularly schemes like those by David Wu and Kevin Lewi, requires a key to perform a query. This is crucial for security, as it prevents arbitrary inference attacks where an attacker could deduce information by observing query results without having the decryption key. While any query reveals some information (e.g., whether results exist), requiring a key for queries significantly raises the bar for an attacker. Other searchable encryption schemes include Symmetric Searchable Encryption (SSE), structured encryption, and encrypted Bloom filters, indicating a rich and active research field.

Demo / Proof of Concept

▶ Watch: The challenge of querying encrypted data. (17:30)

While the talk did not feature a live, interactive demonstration of the entire system, Dan Draper presented compelling benchmarks and conceptual implementations that serve as a proof of concept for the practicality and performance of his proposed data protection architecture.

The core of the proof of concept revolved around contrasting the performance of homomorphic encryption (FHE) with Order-Revealing Encryption (ORE) for database query operations on encrypted data.

For FHE, Draper referenced a Rust library called thfs (likely referring to tfhe-rs or a similar library for Fully Homomorphic Encryption). The benchmark for a single "more than" comparison operation using this FHE scheme showed an average time of 191 milliseconds. This was then extrapolated to a real-world database scenario:

• A query like date_of_birth > '2000-01-01' on a table with 100,000 records.
• With a B-tree index, the query would take approximately 3 seconds.
• Without an index (requiring a sequential scan), the query would take an estimated 5.5 hours.

These figures clearly demonstrated the impracticality of FHE for real-time database querying, effectively serving as a negative proof of concept for that particular approach.

In contrast, for Order-Revealing Encryption (ORE), Draper presented benchmarks showing a comparison operation between two 64-bit integers in Rust taking approximately 200 nanoseconds. This represented an 800,000-fold performance improvement over FHE for the same operation. Applying this to the 100,000-record database scenario:

• A query using a B-tree index would take about 4 microseconds.
• A sequential scan would take approximately 24 milliseconds.

These numbers provided a strong positive proof of concept for ORE's viability in enabling practical queries over encrypted data.

Furthermore, Draper briefly touched upon the practical implementation of ORE within a database context, specifically mentioning PostgreSQL. He stated that their team had successfully implemented ORE by leveraging PostgreSQL's capabilities to create custom operator classes and using PG crypto for HMAC operations within stored procedures. This indicates that while complex, integrating searchable encryption into existing database systems is achievable, providing a concrete example of how the theoretical concepts can be translated into a working solution.

The speaker also mentioned that links to these benchmarks and related papers would be shared on github.com/bsidesSF, allowing attendees to explore and verify the performance claims independently. This commitment to transparency and reproducibility further solidifies the proof of concept presented.

Defensive Implications

▶ Watch: Security implications of ORE and inference attacks. (26:30)

The shift from system-centric to data-centric protection, as advocated by Dan Draper, carries profound defensive implications for organizations. Adopting this model can significantly enhance an organization's security posture against a wide range of threats.

1. Granular, Deny-by-Default Access Control: By encrypting every individual data field, the default state of data access becomes "denied." Only authorized principals with the correct context and keys can decrypt and view the plaintext. This drastically reduces the attack surface and limits the impact of unauthorized access, even if a system is compromised.
2. Universal Policy Enforcement: The centralized key service acts as a single, universal policy enforcement point. This eliminates the need to configure and maintain disparate access controls across various databases, applications, and cloud services. Defenders can manage policies in one location, ensuring consistency and reducing the risk of misconfiguration or policy gaps.
3. Resilience Against Data Breaches and Exfiltration: In the event of a data breach, where an attacker gains access to a database dump or directly to the data store, the exfiltrated data remains encrypted and unintelligible. This renders the data useless to the attacker without access to the key service and the necessary authorization, significantly mitigating the impact of such incidents.
4. Protection Against Shadow IT and Unmanaged Systems: Data often proliferates into unmanaged or "Shadow IT" systems. If this data is encrypted from its origin, its security travels with it. Even if it lands in an unprotected environment, it remains secure, providing a safety net against unknown data sprawl.
5. Enhanced Auditability and Accountability: The key service can be configured to log every successful data key retrieval. This provides a robust and reliable audit trail of who accessed what data, when, and under what context. The guarantee that a data key will not be returned if the log cannot be written ensures a high level of accountability, which is often difficult to achieve with traditional system logs.
6. Secure Data Sharing and Collaboration: The ability to decrypt data in semi-untrusted settings, such as a browser client, opens up new possibilities for secure data sharing. Data can be stored encrypted in local storage or shared platforms, with decryption only occurring client-side after successful authorization from the key service, enabling secure collaboration without exposing raw data.
7. Practical Querying of Encrypted Data: The adoption of searchable encryption schemes like ORE provides a practical way to maintain database functionality (e.g., searching, filtering, sorting) without compromising data confidentiality. Defenders can implement these schemes to allow necessary business operations while ensuring data remains encrypted at rest. However, it's crucial to understand that ORE requires a key to perform queries, and careful consideration must be given to the risk model to prevent inference attacks, where an attacker might deduce information from query results even without direct decryption access.
8. Reduced Operational Overhead (Long-term): While initial implementation may require significant effort, the long-term operational benefits of a centralized, data-centric security model can be substantial. Reduced complexity in managing disparate controls, fewer incidents related to data exposure, and streamlined auditing can lead to a more efficient security operation.

In summary, this approach empowers defenders to move beyond perimeter-based security to an intrinsic data security model, where data is protected at its most granular level, regardless of its location or the systems it interacts with.

Key Takeaways

• Shift from System-Centric to Data-Centric Security: Traditional system-level controls are insufficient; direct encryption of individual data values provides universal, persistent protection regardless of data location or system.
• Encryption as a Policy Enforcement Mechanism: Combining AES GCM with Authenticated Associated Data (AAD), envelope encryption, and key commitment allows a Key Management Service (KMS) to act as a centralized, attribute-based access control point, releasing data keys only when specific contextual policies are met.
• Homomorphic Encryption is Impractical for Real-time Queries: Despite its theoretical appeal, homomorphic encryption's extreme performance overhead (e.g., 191ms per comparison, 5.5 hours for a sequential scan on 100k records) makes it unsuitable for practical, real-time database operations.
• Searchable Encryption (ORE) Offers a Practical Solution for Queries: Order-Revealing Encryption (ORE) provides efficient comparison operations on encrypted data (e.g., 200ns per comparison, 24ms for a sequential scan on 100k records), enabling practical querying capabilities while maintaining data confidentiality, though requiring a key for queries to mitigate inference risks.
• Enhanced Security Posture and Auditability: This data-centric approach provides deny-by-default security, resilience against data breaches, protection for data in unmanaged systems, and robust logging of data access attempts from the key service.
• Flexible Decryption Architectures: The universal interface for decryption allows for flexible deployment options, including decryption in the browser, edge workers, applications, or database proxies, enabling new secure architectural patterns.

About the Speaker(s)

Dan Draper is the Founder and CEO at CyStash, an American and Australian cryptography and data protection startup. He is a longtime software engineer and cryptography engineer. He is an Australian who, despite his nationality, dislikes the beach.