For encryption purposes of some columns I wrote UDFs. I then realized that passing the keys through SQL is nonsense as the SYSDBA can trace SQL and look into session environment. And he exactly is the one, who should not access the data.
Full database encryption is no option for me due to the fact that most of the data does not need to be encrypted and speed is an important thing.
My approach is to transfer the key from client to server with ECC public/private key technique. This is easy to accomplish but where can I store the key for a session within my UDF? Can I get hold of some kind of information about the session of the caller within my UDF?
Related
My requirement is to do column level encryption.
Tried below option
TDE - data is not encrypted to one who has access to database. Please correct me if I'm wrong.
DBMS_CRYPTO package, this works but client wants to store encryption key outside Oracle database.
I'm not able to find solution for storing key outside database.
Any help on this is highly appreciated.
Perhaps two different things here.
To do TDE at column level already uses an external key store, namely a wallet. The location is specified by ENCRYPTION_WALLET_LOCATION in your sqlnet.ora file, and you'd open the wallet when the database starts, eg
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "thePasswordIchose";
Conversely, if you are looking at doing some "home grown" encryption of data using DBMS_CRYPTO, then key management also becomes your own responsibility. You could store the key however/wherever you like, but its your job then to manage it and pass it securely into the DBMS_CRYPTO routines
We need to send data from db2 (db2 for AS400) to another data warehouse platform (Hive). But we need to encrypt data in DB2 first. And then target server will connect to DB2 to export data and decrypt data in target server.
SQL to encrypt data in DB2:
INSERT INTO TESTAES
SELECT ENCRYPT_AES( ACCOUNT, '1234567890') FROM TESTPLAIN;
I know the DECRYPT_CHAR function in DB2:
SELECT DECRYPT_CHAR( ACCOUNT, '1234567890') FROM TESTAES
But after we load this table to another platform, we don't know how to decrypt the data. We don't know the DB2 decryption algorithm.
The way I thinks may works:
(1) Get the decryption algorithm of ENCRYPT_AES in DB2 and we can write a program in targer server to decrypt the data. But IBM shared this in any documents. I searched it in IBM DB2 document, just told us
Encryption algorithm: The internal encryption algorithm used is from the CLiC Toolkit from IBM Research. The 128-bit encryption key is derived from the password using a SHA1 message digest?https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/db2/rbafzscaencryptaes.htm
(2) Get the decryption algorithm package of ENCRYPT_AES in DB2 and we can import this package in targer server to decrypt the data. Did IBM have such package?
(3) Use another open-source/common function/package to encrypt data in DB2. And we know the algorithm and we can write program/or use the same algorithm package to decrypt the data. But I don't how can we encrypt data in AS400 db2 except ENCRYPT_AES. Maybe write a java program or something else?
Would anyone share this experience in encrypted data migration to another platform.
it is standard AES algorithm, but the default CCSID in AS400 is EBCDIC.
do you need to convert DATA to UTF-8 after decryption.
I think this question can be closed. Becuase
(1) I asked IBM Technical Support, he suggest us to write encryption/decryption function by ourselves. Maybe the algorithm of DB2 encryption function is a secret.
(2) I created an DB2 UDF to call Java Program in AS400. Finally, it works. I can encrypt data in DB2 and after other database get encrypted data and it can be decrypted in other database.
Oracle 11.2.0.4.0 enterprise.
We are hosting multiple customers data in single schema, a new customer wants his data to be secure with his unique encryption key.
Using Transparent Data Encryption (TDE), can we somehow create multiple master encryption keys within single schema?
We can upgrade to Oracle 11.2 for that as well if any workaround available.
Lastly if no such thing possible as 'multiple master encryption keys within single schema' then what other approach suits best for us, should we create separate database in same instance or should we commission separate vm-machine for this new customer.
Wishes
We are planning to enable ORACLE TDE in our database for all the tablespaces.
I would like to know what impact it would have on my shell and Perl scripts that run on a client machine. The shell and Perl have username and passwords to connect and execute queries and procedures. Would it not work if I turn on TDE? will I have to use wallets instead of username and password once I enabled TDE?
TDE should be transparent (hence the "T") to applications that are accessing the data. The use of wallets etc is more within the scope of the DBA operations for opening/closing the database, and encrypting the data.
Normal application queries should be unimpacted, and user names and passwords are similarly not affected.
There is a very good FAQ on TDE here
http://www.oracle.com/technetwork/database/security/tde-faq-093689.html
Does anybody knows how could I make a trigger or anything else to prevent people to connect on my database with any kind of applications besides mine?
Note that the super-old-and-unsecure trigger to block few .exe such TOAD or watever does NOT really works, since you can just rename the EXE to MyApplication.exe.
Hints?
An easier method would be to move the security to a role that can be enabled only by your application - see a previous answer of mine here
WIth this method another application may create a session but has no other privileges since the role is not enabled.
You may wish to consider Oracle's Secure Application Roles -- it won't prevent people from logging into the database through a rogue application, but it can prevent them from accessing tables and packages if the application doesn't set the role using the password that only it knows.
You can find an tutorial on deploying it here, although to secure it, you'd have to create the role with a password, and your application would have to know the password when issuing the SET ROLE rolename IDENTIFIED BY rolepassword; statement.
I don't know that Oracle has any functionality to help with this (I could be wrong though) so the next best thing might be to write a small server app that lets you have much better control over the login process and acts as the middle-man between the client apps and the database server. That way, all connections to the database come through your server app, and you can control how your server identifies which client app is legit. This will add a bit of complexity to the system though.
If you don't trust the program name in v$session then the only options that come to mind are to have your application encode the password, so that what they type in isn't actually what's used to connect to the DB; or have your app log in with a private username/password and authenticate users against your own users table instead of having Oracle user accounts for them. Both options make management of accounts more complicated though.
When your application logs on, you call a stored procedure that associates the current oracle session as a "trusted" session. Do this by creating a trusted sessions table with a field for sessionID and trusted bit (and optionally a random hash to prevent user tampering).
Create a system wide trigger, that checks the your current session id (and random hash) to detect if it is trusted. If the session doesn't exist in the table, you don't allow the query, and log off the user.
You should also setup a shutdown trigger to clear the trusted session table on exit.