Enhancing Security - Expert Oracle and Java Security - page 282

Jul 9, 2011 8:32:37 AM oracle.jdbc.pool.OracleDataSource setConnectionProperties
TRACE_1: Public Enter: {oracle.net.wallet_location=(SOURCE=(METHOD=file)
(METHOD_DATA=(DIRECTORY=C:/Users/OSUSER/OSUSER))), oracle.net.encryption_types_client=AES192}
Jul 9, 2011 8:32:37 AM oracle.jdbc.pool.OracleDataSource setConnectionProperties
TRACE_1: Exit
...
00 00 00 00 00 53 45 4C |.....SEL|
45 43 54 20 55 53 45 52 |ECT.USER|
20 46 52 4F 4D 20 44 55 |.FROM.DU|
41 4C 01 01 00 00 00 00 |AL......|
The last few lines are a portion of a packet sent to Oracle database, showing the query that was used.
The entire contents of every packet in both directions are included in the trace log. Data encryption is
not being used. Using trace logging is something to be done while troubleshooting, but it should not be
done in production.
Encrypt Data Stored on Oracle Database
So far, we have encrypted data as it traversed the network between the client and the Oracle database.
We have also encrypted data while in memory, but not in use on the client (the list of connection
strings.) However, we have stored data on the Oracle database in clear text. In particular, we are
concerned for the connection string lists that we have stored on Oracle in clear text. Well, we are going to
address that concern here.
DBMS_CRYPTO Package
Oracle database provides a PL/SQL package that can assist us in doing data encryption at rest (while
data is in storage in the database). By using the DBMS_CRYPTO package, we can selectively encrypt specific
columns of data. Other alternatives exist, including full-table encryption. The Oracle Advanced Security
product, which can be purchased separately from Oracle, can be used to accomplish that.
The DBMS_CRYPTO package is installed by default in the Oracle Database 11g, but it is not enabled by
default. We will enable it for our application security, appsec user. We are going to accomplish
encryption/decryption using a stored procedure that is owned by appsec , but is executed by appver . I'm
telling you this to explain why we are granting execute on DBMS_CRYPTO to appsec instead of to the
app_sec_role . The reason is that no roles exist unless you are in a session, and in the scenario I just
described, no session exists for appsec . At an Oracle SQL command prompt as SYS , we will execute this
command.
GRANT EXECUTE ON sys.dbms_crypto TO appsec ;
Passwords and Keys
Now, as a matter of full disclosure, I hasten to add that DBMS_CRYPTO can be used for a variety of
encryption/decryption tasks. Theoretically, we could do encryption on the client using Java and JCE, and
do decryption on Oracle database using DBMS_CRPTO . There are two problems with that proposal. First,
DBMS_CRYPTO is not nearly flexible enough for us to achieve the same level of security as we have with the
OracleJavaSecure process. And second, DBMS_CRYPTO doesn't act like a single side of an
encryption/decryption communication; rather, it assumes it is the party doing both encryption and
decryption. It doesn't readily exchange encryption keys, nor expose its algorithms.