Skip to Main Content
  • Questions

  • PCI Compliance and DBMS_CRYPTO Key Management

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Robert.

Asked: April 14, 2009 - 3:15 pm UTC

Last updated: October 12, 2012 - 8:16 am UTC

Version: 10.2.0

Viewed 1000+ times

You Asked

Hi Tom,

We are doing analysis for PCI DSS requirements and gaps.
One requirement is that we have to store some of our data in 'unreadable' (encrypted) format.
I am looking into DBMS_CRYPTO to accomplish this.
One of the points in the PCI DSS compliance document (section 3.6.6) requires: "Split knowledge and establishment of dual control of cryptographic keys" e.g. 2 DBAs required to (re)construct key, each DBA knowing only one half of the key.

I don't know how this can be accomplished within the database since any DBA can see anything in the database.

Also, there is the requirement (and good idea) for changing the keys periodically, but wouldn't we would need to store the old keys for a time?

Do you have some comments and/or resources for the practical implementation of this sort of thing?

Thanks!

Robert.

and Tom said...

You really do not want to do this - using dbms_crypto

http://docs.oracle.com/cd/B19306_01/server.102/b14220/security.htm#sthref2681

column level encryption would be a better approach. The key management issue is really hard to solve and using dbms_crypto - not only would the DBA's have to know it, but the applications would as well.

With transparent data encryption, none of the DBA's need to know the key (you can store it separately - outside the database), rekey information and so on

http://docs.oracle.com/cd/B19306_01/network.102/b14268/asotrans.htm#sthref142

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

2 Objections...

Robert, April 17, 2009 - 12:41 pm UTC

Hi Tom,

But with TDE the data is still in clear text when you select it from the database...
while using DBMS_CRYPTO it is *encrypted* if anybody selects it.

Also... TDE is expensive.

What are your thoughts?

Thanks,

Robert.
Tom Kyte
April 17, 2009 - 3:58 pm UTC

so what - you do not use encryption for access control. YOU USE ACCESS CONTROL FOR ACCESS CONTROL.

If I am granted the ability to see a column in a given row in a given table - I am granted that ability (you can secure data down to the cell level).

If I am not, I am not.

You use encryption to protect data in the event of theft (and that is about it). If someone steals your database, they cannot use this data - even though they can bypass ALL ACCESS CONTROL.


If you think buying an out of the box solution is expensive, go ahead and try to implement this yourself - when you get the key management all figured out, let us know.

See you in a couple of years.

Out of the box is not expensive when you consider the implementation costs of things.

Once again.... Thank you Tom!

Robert, April 17, 2009 - 5:08 pm UTC


Encryption/Access Control

Jobin, April 18, 2010 - 3:08 am UTC

Tom,

I agree that encryption is not meant to be for access control. However sometimes there is a requirement that a user should be able to see the decrypted data only through application not through tools like sqlplus. How do you think TDE can help on this PCI requirement.

Regards
- Jobin -
Tom Kyte
April 19, 2010 - 8:42 am UTC

... However
sometimes there is a requirement that a user should be able to see the
decrypted data only through application not through tools like sqlplus. ...

we do that, you can use fine grained access control to control access to data at the application level.

And - it has NOTHING to do with encryption.


Encrypting data does NOT support that PCI requirement. If the user has access to the data - they have access to the data. What you need to do is prevent access to the data. Find grained ACCESS control is about controlling access.

Encryption is not, as you admit.

still not convinced

Pradeep., October 12, 2012 - 6:06 am UTC

hi Tom,

I still tend to disagree.

The access control is set and decided by the DBA. I guess the DBA/SYSDBA/Oracle cannot set an access control in which he can hide data from himself. So eventually all data is visible to those users. I guess that its for this reason that the PCI-storage requirements state that the encryption key should not be tied to the login credentials.

Please state your view on this.

Thanks.
Tom Kyte
October 12, 2012 - 8:16 am UTC

Access control is set by a DBA? since when. Since when does a database adminstrator have enough knowledge of the nuances of an application to be able to decide what should be protected from whom???


"So eventually all data is visible to those users."

which is why you would lock down those accounts - seriously lock them down. Almost NO ONE should have sysdba and in most cases no one should (except for the rare times they need it like during an upgrade). Even the DBA role is too overreaching (but it can be protected from 'seeing' data using access control).

encryption is not access control, it is used to protect data at rest from theft. period.



Sairam, December 18, 2018 - 5:25 pm UTC

For data access to Authorized users only we can define a VPD policy on the table and configure a VPD function in such a way that the data access is only for Authorized users.

The TDE is to secure data at file level.

Thanks,
Sairam.
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.