This article includes a technical document detailing guidelines when using an ADK. An additional decryption key (ADK) is a key generally used by security officers of an organization to decrypt messages that have been sent to or from employees within the organization.
Additional Decryption Keys (ADKs) are created as an additional method to decrypt content where decryption by the intended recipient may not be possible. The holder of the ADK, and corresponding passphrase will allow any content to be decrypted as long as the data was encrypted to this key.
ADKs can be enforced on an Organizational Level, and a Consumer Policy Level. When enforced via the Organizational Level, the ADK applies to all users. When enforced on the Consumer Policy level, the ADK applies to only those users who are part of the applicable policy.
IMPORTANT TIP: Take special care with the passphrase/password of the Additioanl Decryption Key. If the passphrase is lost, the ADK cannot be used and a new key must be generated and applyed and then deployed.
This is a non-trivial event. For more information on changing your ADK, see the following article:
247825 - Replacing or Updating an Additional Decryption Key on Symantec Encryption Management Server may not clean up old ADKs
As a best practice, it is recommended to create ADK on a standalone Symantec Encryption Desktop client. By Standalone, the client is not managed by the Symantec Encryption Management Server (SEMS) for policy assignment. An individual license number is entered, and there is no aspect of the SEMS that controls policy for that key, and subsequently, influence the behavior of the keys.
The reason for using a Standalone client is the ADK should have no association to any other keys in the organization. The ADK is created w/out an expiration date and is not created as per policy, but acting as its own key. Once the ADK is created on the Standalone client, this will ensure no other factors can affect the key.
Keys generated on the standalone client are, by default, set to never expire. Keys that are created when being managed by the server have the potential for having expired signatures because there are no clients that are enrolled with this key.
Choose an appropriate key size for the organization--at least 2048 is recommended.
If splitting the ADK, please take special care with the conditions as once the ADK Keypair is split, the Keypair is no longer usable until re-joined. For example, if the key is split into 3 shares, and 2 are required, if only one user is able to enter his\her credentials, the keypair cannot be joined.
Always take special care to make backups of the ADK, ensuring the Keypair (Both Private and Public) is being backed up, not only the Public Key.
Fixing an ADK, due to Signatures, other ADKs on the key, etc.:
Setting Expired ADKs to Never:
Import the Key Pair into a standalone client of Symantec Encryption Desktop. Once the Key Pair is imported , double-click the key to open the key properties. Click on the "Expiration" field of the key and set it to "Never". Click okay to save the changes and enter a passphrase to confirm the changes.
Removing ADKs on ADKs:
It is important that no ADKs are associated to your designated ADK. Doing this causes confusion and could cause some unexpected results.
To ensure there are no ADKs associated to the ADK you would like to designate on the PGP server, export the ADK Keypair and import into a Standalone PGP Desktop client that is not managed by a PGP server. Once imported, double-click on the ADK, and then click on the ADK card on the key properties. If there is an ADK, remove it. You will be prompted for a passphrase to confirm. Enter the passphrase and once the ADK has been removed from the ADK you would like to upload to the server, close the key properties.
Once you have removed the ADK and it is no longer included on that key, right-click on the ADK that you just updated and click Export. This will allow you to save the ADK public key that you can then upload to the PGP server. It may be a good idea to rename the file "ADK-official.asc", or some other memorable name so that you know this is the ADK key file you should upload to the PGP Server.
Once you have uploaded the proper ADK, backup the keypair and keep it in a safe place in case it is needed in the future.
ADKs are compatible for the following scenarios:
*Individual File Encryption
*File Share Encryption.
*Virtual Disk Encryption
*Group keys are fully compatible with additional decryption keys (ADKs)
*ADKs are Not compatible with Self-Decrypting Archives (SDAs) or "Conventional" Encryption, which uses *only a password* to encrypt.
PGP uses many components to encrypt and decrypt content. When content is encrypted to these keys in the methods listed below, in order to use the ADK to decrypt, the ADK can then be used to decrypt the content. Using the ADK requires importing the keypair into the PGP Keyring. Once the Keypair has been imported, as long as you know the passphrase, you can decrypt the content using the applicable.
For example, if you have a file that was encrypted to the ADK, in order to decrypt the file, you import the ADK Keypair to the keyring and then attempt to decrypt the file. The passphrase prompt will appear for the user and then the file should then decrypt.
If you have a share encrypted with Symantec File Share Encryption, and the share was also encrypted to the ADK, in order to access the encrypted content, simply import the ADK into the keyring and the files can then be accessed.
Having an ADK does not change the method for decryption, it simply changes who would then have the ability to access the content.
Deleting Expired Org Signatures on ADK:
Expand the key by clicking the plus sign and if there is a signature from your Org Key, go ahead and delete it. The signature icon looks like a little pen with a globe on it. This will make the key so that it is unassociated to any other keys.
Remove Preferred Keyservers on ADK:
If there is a preferred Keyserver on the key, remove the entry for the existing server so it is blank.
Once all these steps have been completed, the ADK should be ready to now be uploaded back to Symantec Encryption Management Server.
The purpose of the ADK is to ensure there is a means of decrypting data. When the ADK is uploaded to the Symantec Encryption Management Server, it is automatically signed by the Org Key--this is normal, however, it should not be signed as part of an Enrollment procedure on a Managed Client.
NOTE: An attached Guidelines Document is available for general review. Some of the information in the document may no be completely accurate as far as general guidelines, however the steps to perform Key Generation, Splitting Keys, Joining, etc., can still be used.
The ADK is like any other PGP key and will have the keypair containing a public portion and a private portion.
The public portion is what is assigned the Consumer Policy on the PGP Server and the Private Portion is typically kept in a secure location.
If you need to change the passphrase of the ADK, you would do this as you would any other key. In this example, we will do so with the ADK inside of PGP Desktop:
In this example, the name of the ADK is "ADK".
Double-click on ADK and you will see the Key Properties:
Notice on the top-right corner the option "Change Passphrase". Click this to start the process.
Enter the current passphrase to the existing key and click next:
If you get an error about "Incorrect Passphrase", this means the password is incorrect. Re-enter the proper passphrase and you will see the next screen:
Warning: If you leave the passphrase fields blank, and click next, the key will no longer have a passphrase.
It is important for a PGP Key to have a passphrase as this protects the keypair data.
Now if you would like to export the ADK, there are two ways to do it:
Method 1: Export the Keypair (Public and Private Keys both)
Step 1: Open the PGP Keys in PGP Desktop and right-click the ADK in question.
Click on Export:
Step 2: Click the option "Include Private Keys" to ensure both the Private key and public keys are exported:
Method 2: Export the Public Key (Public key only):
Use all the same steps as Method 1, but *do not* check the "Include Private Keys" option:
There are two possible keymodes that you will typically see with ADKs and PGP Server upon importing as an Organization ADK or Consumer Policy ADK:
Client Key Mode (CKM): This keymode means that you imported only the Public portion of the key to the PGP Server.
Guarded Key Mode (GKM): This keymode means that you imported the keypair to the PGP Server, but the server does not know the passphrase.
If you need any additional guidance for ADKs, reach out to Symantec Encryption Support for further assistance.