Scenario: Multiple users need to share a key and each of the users must be unique. The users need to have access to the keypair, but the key needs to be protected so that if the private key is ever exported and taken to another system, the key must remain unusable.
This scenario is possible when using Symantec Encryption Management Server (SEMS) in Server Key Mode (SKM Mode). SKM Mode provides individual users with a keypair in which the end user never needs to enter a passphrase, and the key is protected while in the local keyring managed by Symantec Encryption Desktop.
Access to this SKM key is available by uploading the keypair to the SEMS after adding additional User IDs to it and removing non-user specific User IDs. When the users enroll, the SKM keypair is downloaded from the SEMS. A random passphrase that is not know by any user is assigned the key. When the user logs in to Windows, the SKM key is unlocked.
Even if the keypair is exported from the local encryption desktop keyring, the random passphrase protects the key and this is not stored anywhere for access.
This document goes over the steps on how to configure this key, and using Symantec Encryption Desktop to make needed modifications to a Keypair.
Considerations: Because this article deals with a keypair, it is advised that multiple administrators be present to ensure chain of custody of this keypair. Once a keypair is exported to a desktop, it will be usable. Once the necessary modifications have been made to the keys, the keypairs with the known passphrase should be securely wiped.
Definitions: In this document, we’ll refer to the SED client that enrolled with SEMS the “Managed” client. For the SED client that is not enrolled to the server, we’ll refer to this system as the “Standalone” client.
Prerequisites: Two to three machines that have Symantec Encryption Desktop. At least one machine will be a standalone client that will be used to make needed modifications to the key for final upload to the SEMS to individual user accounts.
Part 1 of 3: Creating, Modifying and Uploading a Shared Key
Step 1: Create a Consumer Policy on SEMS and within the key settings, check only the SKM option:
Step 2: Create the keypair. The preferred method to create this key is to enroll the first user to the SEMS using a managed client, which will create the SKM key.
Step 3: Once the first user is enrolled, login to the SEMS and download the keypair to the standalone machine. In this test, we have enrolled a user named “Kevin”
Step 4: Once enrolled, notice the key and how it was generated. In this example, the managed domain is sr388.dom, so the organization will be downloaded as well:
Step 5: Now double-click on Kevin’s key to display the key properties. Notice the Key ID is 0x88EE78AEE. This is important as we go through these steps. The Key ID is unique to each key and in this scenario, we will be using this same key for multiple users to create a “Shared” key situation:
Also notice that there is no ability to “change passphrase” in the Key Properties. Because this is an SKM, it is protected with the random passphrase that nobody knows, and therefore, there is no passphrase entry. Even if you export the keypair, and import to another SED client, the key will be unusable, because there is no known passphrase.
Step 6: Next we will be adding an additional user ID to the 0x key named “Brian”. We need to go to the standalone client to make these changes. Login to the SEMS and under Keys, Managed Keys, look for Kevin’s key with the associated Key ID:
Click the Key, and then click Export:
Select Keypair, and enter a passphrase that only you and additional security members will know and then click Export, and save the file to the standalone machine where we will be making these changes. Give it a name “Kevin-SKM-Exported-Keypair.asc”:
Step 7: On the standalone machine, import the keypair you exported from the SEMS. To do this, double-click on Kevin’s key and confirm the prompts to import.
Step 8: Now open the Key properties of Kevin’s key, similar to Step 5. Click on “Add Email Address”. In this example, we will add user “Brian”, with the associated email address. Once you click “OK”, you will be prompted to enter the passphrase for Kevin’s key to add the additional User ID:
Step 9: Once Brian’s user ID is added, we will set “Brian” as the “Primary Name” for the key. To do this, right-click the envelope for Brian, and select “Set as Primary Name”. Confirm Kevin’s passphrase again:
Step 10: Now Brian’s User ID will appear as the primary ID. Delete Kevin’s User ID by right clicking the key and selecting “Delete”:
Step 11: Once you delete Kevin’s user ID, the key now looks only like Brian’s key, however, the Key ID will still be the same. Adding an additional user ID, simply adds a name to the key, but the PGP fundamental key material remains the same.
Notice the Key ID did not change:
Step 12: With Kevin’s User ID removed from the key, export the Keypair so that only Brian’s User ID and associated email address appear on the key. To do this, right-click the key and choose Export, and then be sure to check the box “Include Private Key(s)”, and then give it a name. In this example, we’ll name it “Brian-SKM-Exported-Keypair.asc”. Save this along with Kevin’s keypair from Step 6.
Step 13: Now we are going to add yet another User ID by following the same steps as before, but this time we’ll use he User ID of “Bill”. Be sure to delete the Brian User ID similar to how we did before:
After following the steps as before, you’ll end up with key looking completely different, now named “Bill”:
Notice the Key ID. It hasn’t changed. Now Export the keypair and this time, give it a name of “Bill-SKM-Exported-Keypair.asc” and save to the same place. Now you’ll have three keys, one for Kevin, Brian, and Bill.
Step 14: We should already have a user on the SEMS called “Kevin”, but now we want to upload the two exported keys for Bill and Brian to the SEMS. This will create two new users by these names, and each of them will have the same key.
First, upload Brian’s key under Consumers, Users, Internal Users. Select “Add Internal Users”:
Next, browse to Brian’s key, and then enter the passphrase of the key (previously created when exporting Kevin’s key from the SEMS):
By entering the passphrase, this sets the keymode as “SKM”, just like Kevin’s key. Do the same for Bill’s key. You’ll now have three unique users using the same key (notice the Key ID is the same):
Part 2 of 3: Encrypting to the Shared Key, and decrypting as each individual user.
Now that we have three unique users with the same key, enroll these other users. This can be done by logging out of Kevin’s profile, and then logging in as Brian and Bill’s profile. The enrollment prompt will appear for each user. Enroll as you did for Kevin, and as you do, you’ll notice the same SKM Keypair will be downloaded to each individual user’s local keyring.
Because it’s SKM, the keypair is downloaded in a protected mode with the random passphrase. This gives access to the keypair for each of these uses, but they will not be able to make any modifications to the key, or export the key and import to another client. The only way this key can be used, is if the users enroll to the SEMS as these accounts.
For this next part, we will encrypt a file to the shared key, and demonstrate that each of the other users can decrypt, all without needing to enter a passphrase.
Reminder: The passphrase is not needing to be entered, because the key is authenticated as the users login to Windows. There is a cryptographic operation that happens to unlock the random passphrase securely.
Step 1: Login as Bill and encrypt a file to Bill’s key first. In this test, we’ll encrypt the file “Step12-bill.png”. Right click the file, choose Encrypt from the Symantec Encryption Desktop context menu, and in the Key Selection Dialogue, choose Bill’s key:
Note: Although this is “Bill’s” key, the Key ID is the same as Kevin and Brian’s key. The resulting file will be ““Step12-bill.png.pgp”. The .pgp extension indicates it was encrypted:
Step 2: As Bill, delete the unencrypted file and then right-click on the encrypted file and choose Decrypt. This will decrypt and output with the original filename.
Step 3: Next, login as Brian and Kevin and go through the same steps to decrypt the encrypted file. Because the file was encrypted to the same Key ID, these users will have access to decrypt.
Note: Instead of right-clicking to decrypt, a faster way to decrypt is to simply double-click the file.
Part 3 of 3: Removing Access to the Shared Key
Because each of these users have a shared key, we would assume the reason it’s shared is to perform a duty for a specific group. If this user should no longer have access to this shared key, it is required to do a cleanup of the keys for the user so that they can no longer use the shared key. This section will go over how to remove the keys from the client and the server.
Step 1: In this example, Brian no longer needs access to this shared key, so we will login as Brian and open the Encryption Desktop client. Click on Brian’s key, and select “Delete”.
You’ll get a prompt that you are deleting Bill’s key. Click OK to confirm:
You will be prompted again to double confirm you want to delete the keypair. Brian’s keypair will now be removed from the local keyring in Symantec Encryption Desktop and only the Organization Key will remain:
Step 2: Exit the Symantec Encryption Desktop services from the taskbar menu. Next, go to %appdata%\PGP Corporation\PGP and delete the PGPprefs.xml and PGPpolicy.xml files. This will essentially “unenroll” the client from the SEMS.
Step 3: Login to the SEMS and open up Bill’s account under Consumers, Users, Internal Users, and click on Brian. Next, click on “Managed Keys, and you’ll see Brian’s key listed. Click the “Delete” icon on the right right and click OK to confirm.
Brian’s key should now be removed from the SEMS and Brian will no longer have access to this Shared key:
Step 4: Now with Brian’s key removed, you can re-enroll Brian, and a new key will get created. This time the Key ID will be different than the Shared key.
Step 5: To validate Brian no longer has access, attempt to decrypt the file from the previous decryption test. Upon attempting to decrypt, the following error will appear, indicating the proper keypair is no longer available in the keyring for Brian:
Step 6: If the Shared Keypair was exported while the user was enrolled with the managed client, and then imported into an unmanaged client, not enrolled properly to the SEMS, there will be a random passphrase on the key that will protect the key, however because this is a random, unknown passphrase, the key cannot be used to decrypt or sign any longer:
Because the random passphrase is protecting the key, there is no way to use the key, even if the keypair is available.