Automated Daily Aes Encryption Key Changes (Doc ID 741932.1)

Last updated on SEPTEMBER 25, 2015

Applies to:

Oracle Communications Billing and Revenue Management - Version: and later   [Release: 7.3.0 and later ]
Information in this document applies to any platform.
***Checked for relevance on 23-Jan-2012***


Some concerns with encryption key generation and rotation requirements:

1) It appears that the key stored in the dm_oracle/pin.conf file is only loaded at process startup.
    Is it possible to cause the Oracle Data Manager to reload the key on demand?

2) The format for encryption key sequences is "&aes|nnnn|<key>", where "nnnn" appears to be a 4 digit base-10 whole number with leading zeros.

    a) This appears to limit the number of active (1) and historical keys to a total of 10,000, i.e. 0000 to 9999.  Is this correct? What happens if that number is exceeded?

    b) Assume there may be multiple Oracle DMs each with its own randomly generated keys, such that there could be up to 3 new keys generated daily. That would mean the number of stored keys runs out in 3,333 days or slightly more than 9 years (see (a) above), but one would assume that these keys are cached in Oracle DM memory, which implies that keys stored by one Oracle DM on startup would not be available to other Oracle DMs already running, correct?
    c) Assume that there are 5000 stored keys in place - does this affect decrypt performance?
        The customer would hope not since the index # should allow for direct access to the correct key from a memory cache?

If there is no "refresh" capability at all in the DMs such that they only know the keys at startup time plus the new one each one may have created, then we MUST make sure that the DMs have the same new key each time the encryption keys are rolled to the next value AND make sure that the DMs don't restart at the same time and thus generate 2 indexes for the same key in the database table.

    a) What is the procedure to be followed for deploying a new crypt key for a multi-machine (i.e. multi-Oracle-DM) environment?

    b) Instead of trying to synchronize DM startups so that the first DM can insert the new crypt key value in the cryptkey_t table, how about we pre-load the value directly into the table before updating the pin.confs of the multiple DMs then restart the DMs to load the crypt key cache again?


Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms