Re: Enquiry about TDE with PgSQL - Mailing list pgsql-general

It's always entertaining to read PCI DSS...

In the "guidance and purpose" column of page 95, the standard reads:

     Disk-level encryption typically encrypts the entire disk
     or partition using the same key, with all data
     automatically decrypted when the system runs or when
     an authorized user requests it.

Granted, there would be benefits from a more fine grained encryption, 
e.g. where you'd encrypt PAN data with a different key. I guess that 
would be called column encryption. But I don't think any version of TDE 
implements it that way. The best I've seen is per tablespace.

Further:

     Many disk-encryption solutions [..] perform the appropriate
     cryptographic transformations without any special action by the user
     other than supplying a password or passphrase at system start-up or
     at the beginning of a session.

Well, isn't that exactly how TDE also works? It loads the key at 
start-up (of the database system, not the operating system, but that's 
equivalent for dedicated database servers) and decrypts "without any 
special action by the user". Otherwise, it would not be very transparent.

     This provides no protection from a malicious individual that
     has already managed to gain access to a valid user account

I see a point here in possible separation of concerns. With a sysadmin 
being able to manage the system, but not having (direct) access to the 
data. That's more of an obscurity rather than hard security, though (as 
the key likely is somewhere in memory fully accessible for a malicious 
sysadmin). Still potentially beneficial in combination with all the 
auditing etc...

So, my conclusions:


  * some potential process level security, no scientific security gains
  * most (if not all) existing TDE products on the market don't actually
    satisfy the stated purpose (or differ enough from disk-level
    encryption)
  * these look like unnecessary hurdles pushed into the standard by
    companies trying to shake off competitors who miss these (somewhat
    dubious) features
  * as an OSS project, it's still pointless to fight the standard and
    much more feasible to just implement that darn feature.

Best Regards,
Markus


On 10/31/25 15:54, Bruce Momjian wrote:
> On Fri, Oct 31, 2025 at 03:01:48PM +0100, Kai Wagner wrote:
>> As I personally believe, there is no real way around TDE in the future, either
>> by extensibility of the core (start with the storage manager and move your way
>> on from there), to make an extension possible, or by directly adding it to the
>> core, there are more reasons coming or are already on their way.
>>
>> With the PCI DSS v4.1 standard, one key rule to comply with is, that "If PAN is
> 
> Uh, I think you mean the 4.0.1 standard, which became active on January
> 1, 2025.  I am surprised this is only being mentioned now:
> 
>     https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
>     
>     When will PCI DSS v4.0 be retired?
>     
>     As with all new versions of PCI DSS, there will be a period where both
>     the current and updated version will be active at the same time. PCI DSS
> -->    v4.0 will be retired on 31 December 2024. After that point, PCI DSS
> -->    v4.0.1 will be the only active version of the standard supported by PCI
>     SSC.
> 
> While it was active on Jan 1, it became effective on March 31, 2025:
> 
>     Does PCI DSS v4.0.1 change the 31 March 2025 effective date for the new
>     requirements?
>     
>     No. This limited revision does not impact the effective date of these
>     new requirements.
> 
>> stored, it must be rendered unreadable". Of course there are other ways, like
>> tokenization, hashing etc. but this regulation is pushing towards at rest
>> encryption in the long run, and not only disk encryption. We can dislike it,
>> but we are already seeing the need coming from large industries and companies
>> that they cannot work around this anymore, as the auditors doing the checkboxes
>> do not really care about "good alternatives", as they do not even technically
>> understand what this is about. They do compare postgres simply against other
>> already in use databases at these orgs (MySQL or MongoDB), and as such, we are
>> currently the only one that cannot be used in such a use case, at least not
>> without the willingness of the auditor to make it happen.
> 
> I see the new specification that disk-level encryption is insufficient,
> starting on page 93 (page 97 in the PDF URL):
> 
>     https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=97
> 
> -->    3.5.1.2 If disk-level or partition-level encryption (rather than
>     file-, column-, or field-level database encryption) is used to
>     render PAN unreadable, it is implemented only as follows:
>     
>     • On removable electronic media
>     
>     OR
>     
>     • If used for non-removable electronic media, PAN is also
> -->    rendered unreadable via another mechanism that meets Requirement
>     3.5.1.
> 
>     ...
> 
>     While disk or partition encryption may still be present on these
>     types of devices, it cannot be the only mechanism used to protect
>     PAN stored on those systems. Any stored PAN must also be rendered
>     unreadable per Requirement 3.5.1—for example, through truncation
>     or a data-level encryption mechanism. Full disk encryption helps
>     to protect data in the event of physical loss of a disk and
>     therefore its use is appropriate only for removable electronic
>     media storage devices.
> 
>     Purpose
> 
>     Disk-level and partition-level encryption typically encrypts
>     the entire disk or partition using the same key, with all data
>     automatically decrypted when the system runs or when an authorized
> -->    user requests it. For this reason, disk-level encryption is not
> -->    appropriate to protect stored PAN on computers, laptops, servers,
>     storage arrays, or any other system that provides transparent
>     decryption upon user authentication.
> 
> PAN is:
> 
>     https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=391    
>     
>     PAN Acronym for “primary account number.” Unique payment card
>     number (credit, debit, or prepaid cards, etc.) that identifies
>     the issuer and the cardholder account.
> 
> So it seems we have somewhat of a stand-off, with the Postgres project
> questioning the value of TDE and the PCI writers doubling-down on
> specifying disk-level encryption as insufficient.
> 
> The biggest possible downside of this standoff is that enterprises that
> need to meet PCI compliance specifications are forced to use specialized
> versions of Postgres or Postgres extensions that support TDE.
> 
> The fact that it has been seven months since PCI 4.0.1 was effective,
> with little to no discussion or movement on adding TDE to community
> Postgres means to me that we are unlikely to see TDE added to community
> Postgres anytime soon.  I have a small hope that adding compression to
> the writing of temporary files will reduce the code changes needed to
> encrypt temporary files, thus reducing the amount of TDE code changes
> needed.
>