Dell EMC Data Domain Encryption - Frequently Asked Questions
Uploaded by
jorge.silveraDell EMC Data Domain Encryption - Frequently Asked Questions
Uploaded by
jorge.silveraKnowledge Base Article: 000303747
Dell EMC Data Domain Encryption - Frequently Asked Questions (000303747)
Primary Product : Data Domain
Product : Data Domain
Version: 4 Article Type: How To Audience: Level 30 = Customers Last Published: Thu Jun 15 11:23:11 GMT 2017
This knowledge article provides a collection of frequently asked questions (FAQ) in a consolidated location for ease of
Summary:
reference.
Instructions: General Questions
What is the DD Encryption software option?
The DD Encryption software option provides an inline encryption capability that encrypts the incoming data and stores
the data on the disk in an encrypted format.
What is the most significant advantage of the Data Domain inline encryption?
The most significant advantage of inline encryption is increased security since data is encrypted before being stored on
the disk. With an inline approach data does not reside in a vulnerable, unencrypted state on the disk subsystem. In
contrast, post-process deduplication approaches that first store data and perform deduplication at a later time have a
lengthy window of vulnerability with data waiting to be deduplicated and then encrypted. This architectural artifact of
post-process deduplication systems severely compromises the security of such a solution. Therefore, any safe and
secure data-at-rest encryption solution paired with deduplication must be done in-line.
What is the threat model that data-at-rest encryption protects against?
The DD Encryption software option encrypts all incoming data before it writes the data to the physical storage media.The
data is physically stored in an encrypted manner and cannot be accessed on the existing system or in any other
environment without decrypting it first. Encryption of all data at rest helps satisfy IT governance and compliance. It
protects the user's data against theft of a Data Domain system and loss of the physical storage media during transit, and
eliminates accidental exposure during the replacement of failed drives.
How does data-at-rest encryption protect against data access from users and applications?
It doesn't. Encryption of data at rest is all about encrypting the data, which resides on the disk subsystem.
To a user or backup application that has the appropriate privileges and permissions (CIFS share, NFS mount, Data
Domain Virtual Tape Library [VTL] tape device, DD Boost storage unit), this is all transparent as encryption/decryption
happens at the compression layer. Users and/or applications send and receive clear text data to the Data Domain
system, but any data physically residing on the Data Domain system is encrypted.
Quite simply, all encryption occurs below the file system and namespace and is invisible to the users and/or applications.
If a user or application already has authorized access to a file or directory, the data can be read in its native format
regardless of encryption.
DD Encryption is designed such that if an intruder circumvents other network security controls and gains access to
encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.
What changes need to be made on clients once encryption is enabled?
None - encryption of data at rest is transparent to clients. Data written to the DDR is received as normal then encrypted
during write to disk on the DDR. Likewise, data on the DDR is decrypted during read then sent to clients in its
original/unencrypted form.
Where does the encryption key get stored?
Multiple copies of the encryption key are stored on multiple RAID groups within the Data Domain Platform
Can Data Domain's encryption at rest feature be used simultaneously with the Extended Retention option?
Prior to DD OS 5.5.1, these two features are mutually exclusive, and Extended Retention cannot be enabled until all
encryption-related configuration is removed and no data is encrypted. Note that there was a bug prior to 5.5.0.8 that
would allow ER to be enabled even if there was previously-encrypted data, which could leave the system in an unusable
state.
Starting with DD OS 5.5.1, Encryption of Data at Rest is supported for DD Extended Retention enabled systems with a
single retention unit.
Does pre-existing data get encrypted once encryption is enabled?
Starting with Data Domain Operating System (DD OS) 5.0, existing data on the Data Domain (DD) system can be
encrypted however this does not happen by default. This can be accomplished by using the 'filesys encryption
apply-changes' command after encryption is enabled, which will then encrypt previously stored data during the next
global cleaning cycle. If this option is not specified then only newly ingested data will be encrypted and all existing data
(written to the system prior to encryption being enabled) will remain unencrypted.
What security control is required for changes to the data encryption feature?
DD OS 5.0 introduces a new security officer role for dual authentication. This authentication provides a security audit trail
for changes to data encryption status. One administrator user and one security officer user credentials are required for
various commands changing the status/configuration of encryption.
What encryption standards are used and what compliance standards does the product meet?
The DD Encryption option uses industry-standard AES encryption algorithms for encryption of the key(s) and user data:
FIPS 140-2 validation: DD Encryption uses RSA's BSAFE libraries, which are FIPS-validated and certified. However, the
Data Domain system cannot be claimed as FIPS-certified since EMC has not gone through the validation and
certification process.
The Payment Card Industry Data Security Standard (PCI-DSS) is a comprehensive collection of policies and general
requirements for access/authentication, which would apply to any appliance that is processing, moving, or storing data.
There is no known certification process or validation required of any computing system. Although PCI-DSS calls for
encryption, it only relates to very few data elements, not the whole environment. Much of the document is open to
interpretation by the customer and it is incumbent on them to decide which aspects they require and to what extent the
current DD Encryption product satisfies those requirements.
Which encryption algorithms can be selected on the Data Domain system?
The DD Encryption software option provides an administrator selectable 128-bit or 256-bit Advanced Encryption
Standard (AES) algorithm for encrypting all data within the system. Depending on individual IT security policies, the block
cipher modes for the AES algorithm can be set to provide either confidentiality or message integrity using Cipher Block
Chaining (CBC) or Galios/Counter Mode (GCM). In the CBC mode, each block of plain text is exclusive ORed with the
previous cipher text block before being encrypted. GCM is for symmetric key cryptographic block ciphers. It is an
authenticated encryption algorithm designed to provide both authentication and privacy.
Which block cipher modes does DD Encryption support?
Galios/Counter Mode, which is recommended by NIST Special Publication 800-38D and is an official standard:
GCM is a mode of operation for symmetric key cryptographic block ciphers. It is an authenticated encryption algorithm
designed to provide both authentication and privacy (confidentiality). GCM is defined for block ciphers with a block size
of 128 bits.
As the name suggests, GCM combines the well-known counter mode of encryption with the new Galois mode of
authentication. The authentication aspect of GCM guarantees that the data that was encrypted was done so by the Data
Domain system and wasn't "injected" by some other means. This differs from CBC where data is encrypted (privacy
aspect), but there is no check for the authenticity of the encrypted data.
Cipher Block Chaining mode, which was invented by IBM in 1976:
In this mode, each block of plain text is exclusive ORed with the previous cipher text block before being encrypted. This
way, each cipher text block is dependent on all plain text blocks processed up to that point. Also, to make each message
unique, an initialization vector must be used in the first block.
CBC only guarantees the privacy (confidentiality) of the data through encryption. No authentication of the encryption
algorithm/process is done.
What aspects of the data on disk are not encrypted?
Fingerprint information, file system meta data, and data stored in NVRAM are not encrypted.
Can encryption be enabled on a more granular basis than the entire collection?
No, encryption at this time is all or nothing. When enabled, all data is sent to the system regardless of protocol or access
method encrypted. In this way, the entire collection is encrypted.
Which backup applications are supported with the DD Encryption option?
Refer to the 'Backup Application Matrix' on the Data Domain Support Portal. DD Encryption greatly simplifies the
encryption management since the encryption is done on the Data Domain system transparent to the applications writing
to it. This allows the ultimate flexibility in selecting and changing your backup applications without impacting the
encryption process. Additionally, multiple backup applications can be used concurrently as well as going beyond backup
for archiving and nearline types of data.
Which protocols are supported with the data-at-rest encryption feature?
The data-at-rest encryption feature supports the following protocols: CIFS, NFS, DD VTL, DD Boost, and NDMP. Data
written from all supported data access approaches and protocols is encrypted seamlessly on the Data Domain system.
This allows full flexibility in selecting the protocols used and accommodates changes that might occur in IT policy at a
future point without impacting existing security policies.
Which platforms are supported with the data-at-rest encryption feature?
The data-at-rest encryption feature is supported on all the single controller Data Domain systems, excluding those
configured with the extended retention feature (which is only supported from DDOS 5.5.1.x onwards as long as the
system only has a single archive/retention unit).
Note: Data Domain Global Deduplication Array (GDA) does NOT support the DD Encryption option.
What is the observed impact on storage consumption when encryption is used?
It's negligible with roughly 1 percent overhead associated with storing some encryption parameters with user data.
What is the observed impact on throughput (writes and reads) when encryption is used?
The impact on ingest throughput when encryption is used can vary with the protocol and platform. There does not seem
to be any noticeable performance difference between AES 128 and AES 256, however.
In general, the following percentages are conservative performance degradations in aggregate throughput:
Mode Gen0 Writes (first full) Gen1-40 Writes (Incrementals) Reads
CBC ~10% ~15-20% ~50%
GCM ~50% ~15-20% ~40%
Due to the above encryption should only be enabled on larger systems with more CPUs/cores or systems with significant
overheads in terms of free resource or where performance is not a concern
What role does the Global Cleaning process play in Encryption-At-Rest; and is there a performance impact?
Enabling of encryption of data at rest has a small impact on the performance of global cleaning. This is because data
which needs to be read from existing containers on disk and written to new containers may need to be read, decrypted,
and uncompressed before being re-compressed, encrypted, and written back out to disk. The impact of
decryption/encryption, however, should be minimal but generally depends on the type of data being ingested by the DD.
If encryption is enabled on a DD holding a significant amount of pre-existing data and the 'filesys encryption
apply-changes' command is run then the subsequent global cleaning cycle will attempt to encrypt all existing data on the
system. This means that all data will need to be read, uncompressed, compressed, encrypted, and written out to disk. As
a result the first global cleaning cycle after running 'filesys encryption apply-changes' may take significantly longer than
normal. Customers should ensure that they have sufficient free space on their DD system to allow cleaning to run to
completion without the DD system becoming full (otherwise backups will fail).
Encryption and Replication:
Are DD Replicator and DD Retention Lock software options supported and interoperable with the DD Encryption
software option?
Yes, DD Replicator and DD Retention Lock can be used in conjunction with the DD Encryption option.
Can the DD Encryption be enabled concurrently with the over-the-wire encryption feature in the DD Replicator
software option?
Yes. The Data Domain Encryption software option encrypts data when stored at rest on the Data Domain storage
system, while Data Domain Replicator encryption option encrypts and decrypts data in-flight when replicated between
Data Domain systems. Both can be enabled concurrently and achieve different security goals.
What happens if both the DD Encryption software option and the over-the-wire encryption feature in the DD
Replication software option are enabled concurrently?
If both the DD Encryption software option and over-the-wire encryption feature are enabled on both the source and
destination Data Domain systems, the data already encrypted by DD Encryption is effectively encrypted a second time
by DD Replicator before it is replicated over the network.
At the replica (i.e. the destination Data Domain system), DD Replicator removes one layer of encryption, but the data will
be stored on disk in encrypted format using the encryption key at the replica.
What type of encryption algorithm is used for Data Domain's "encryption over the wire" feature, with regards to
encrypting the replication traffic?
From the Data Domain 5.0 Administration Guide (page 366): "Encrypted replication will use the ADH-AES256-SHA
cipher suite."
Do both the source and destination systems need to be running DD OS 4.8 or higher to use the data-at-rest
encryption software option?
Yes, both source and replica systems must have a DD OS version that supports encryption. For example, DD OS 4.7
replicating to 4.8 (or higher) with encryption enabled does not work.
Do both the source and destination systems need to be running the same version of the DD OS to use
encryption with replication?
The use of encryption of data at rest imposes no specific restrictions on the versions of DD OS which can be used in a
replication pair - any versions of DD OS which are 'compatible' with each other (in terms of replication) can be used as
long as both are DD OS 4.8 (when encryption of data at rest was first introduced) or later.
Please refer to specific DD OS release notes to determine compatible versions of DD OS for various replication
topologies.
How does encryption work with directory or mtree replication?
If both source and destination have encryption enabled:
All data sent directly to the source Data Domain system (e.g. through backup) is encrypted with the source system's key.
This encryption work is being done by the source Data Domain system.
When replicating, the source decrypts the local data, re-encrypts it using the destination system's key, and then
replicates the encrypted data to the destination Data Domain system. This encryption work is being done by the source
Data Domain system.
Any data sent to the destination Data Domain system outside of replication (e.g. direct backup at remote site) is
encrypted using the destination system's key. This encryption work is being done by the destination Data Domain
system.
If source has encryption disabled and destination has encryption enabled:
All data sent directly to the source Data Domain system (e.g. through backup) is not encrypted (for obvious reasons)
When replicating, the source encrypts the data using the destination Data Domain system key and then replicates the
encrypted data to the destination Data Domain system. This encryption work is being done by the source Data Domain
system.
Any data sent to the destination Data Domain system outside of replication (e.g. direct backup at remote site) is
encrypted using the destination Data Domain system's key. This encryption work is being done by the destination Data
Domain system.
If source has encryption enabled and destination has encryption disabled:
All data sent directly to the source Data Domain system (e.g. through backup) is encrypted with the source system's key.
This encryption work is being done by the source Data Domain system.
When replicating, the source decrypts the data and then replicates the unencrypted data to the destination Data Domain
system.
Any data sent to the destination Data Domain system outside of replication (e.g. direct backup at remote site) is not
encrypted.
How does encryption work with collection replication?
Note that when using collection replication replication it is required that both DD systems in the replication pair have
matching DD OS versions and configuration. As a result encryption must either be enabled or disabled on both systems
in the pair.
If source and destination both have encryption enabled:
All data sent directly to the source Data Domain system (e.g. through backup) is encrypted with source system's key.
This encryption work is being done by the source Data Domain system.
When replicating, the source just sends (replicates) the encrypted data to the destination Data Domain system in its
encrypted state. The destination Data Domain system has the same key as the source since it is effectively an exact
replica of the source Data Domain system.
No data can be written to the destination Data Domain system outside of replication, as the destination is a read-only
system.
If source and destination both have encryption disabled:
All data sent directly to the source Data Domain system (e.g. through backup) is not encrypted (for obvious reason)
When replicating, the source just sends (replicates) the data in an unencrypted state and it remains unencrypted at the
destination Data Domain system.
No data can be written to the destination Data Domain system outside of replication, as the destination is a read-only
system.
Does DD Encryption need to be licensed and enabled on both the source and the replica when using
replication?
Yes, if using collection replication. If not collection replication will stop the replication process and an error message will
be logged.
Not necessarily if using mtree or directory replication. DD Encryption can be licensed and/or enabled on either the
source or replica independently depending on what your customer wants to achieve. However, both the source and
replica must have a software version that supports encryption (DD OS 4.8 or greater). Note that there is a separate FAQ
on MTree Replication 180842.
Do the passphrases on both the source and replica need to match when using replication?
Yes if using collection replication. If passphrases to not match collection replication will stop the replication process and
an error message will be logged.
No if using mtree or directory replication. There can be different passphrases between the source and replica.
Do all the encryption parameters need to be the same on source and replica to use collection replication
(includes algorithm setting, etc.)?
Yes. If parameters are different, collection replication will stop the replication process and an error message will be
logged.
What happens if encryption is enabled after collection replication has been replicating for some length of time?
Any new data ingested by the source DD will be written to disk in an encrypted state
This data will then be replicated to the destination in an encrypted state
Any data residing on the source or destination DD prior to encryption being enabled will, by default, be left in an
unencrypted state
To force encryption of existing data the 'filesys encryption apply-changes' command should be run on the source
The next time cleaning runs on the source all existing data will be rewritten in an encrypted state
These changes will also be replicated to the destination system leaving all data fully encrypted on both systems
With encryption enabled on the replica, do both the replicated data and data from some other access point (e.g.
local backup) get encrypted? Is there a way to separate the two on the replica where only the replicated
directories are encrypted while other access is not encrypted?
No. All data is encrypted at the replica regardless of entry point.
How is the key exchange done between source and destination during directory/MTree replication?
During the association phase of replication, the target machine will securely transmit its current encryption algorithm and
key information to the source. Replication contexts are always authenticated with a shared secret. That shared secret is
used to establish a 'session' key using a Diffie-Hellman key exchange protocol. That session key is used to encrypt and
decrypt the Data Domain system encryption key.
In the absence of certificates or PKI key pairs, how is the destination's encryption key protected during the key
exchange?
There is a shared secret between all Data Domain replication pairs that is used to establish a shared session key using a
Diffie-Hellman key exchange. That shared key is used to encrypt the destination's encryption key.
There is a difference between the shared secret used for replication authentication and the shared session key, which is
allocated using the Diffie-Hellman key exchange protocol.
The shared secret used for replication authentication is established by the Data Domain software the first time two Data
Domain systems want to establish a replication context. It is also agreed upon through a Diffie-Hellman exchanged using
parameters embedded in the code. This is persistently stored in the systems to authenticate every replication session
between the two systems.
The replication session key (the key used to encrypt the destination's encryption key) is established using another
Diffie-Hellman exchange with the previously established shared secret, thereby driving the secure key exchange
protocol. This key is not persistent and is only around while the replication context is active.
Is the destination's key stored indefinitely on the source Data Domain system?
The destination's encryption key is never stored on the source Data Domain system. It is only held in memory
(encrypted) while the replication session is active.
How is the destination's key protected while being used by the source?
It is stored encrypted in read-only memory and purged after the replication session has completed.
Encryption Key Management:
How many individual encryption keys can be stored on the Data Domain system?
Prior to DD OS 5.4, only one encryption key is available for all data on the Data Domain system (starting with DD OS
5.0). This one key is stored in multiple places to guard against possible loss or corruption.
Starting with DD OS 5.4, local key management with key rotation was added with the same key types and states, with up
to 254 keys allowed (see DD OS 5.4 release notes for more information).
How is the encryption key generated?
The encryption key is generated using the RSA libraries.
How is the encryption key encrypted on the Data Domain system?
It is encrypted using an AES 256 algorithm. The encryption key and initialization vector are generated by RSA BSAFE,
both seeded from the passphrase and used to drive the AES encryption process. The passphrase is not used to create
the encryption key; it is used to create the encryption key that encrypts the Data Domain system encryption key. Note
that changing the passphrase doesn't change the underlying Data Domain system's encryption key. Changing the
passphrase changes the encryption of the Data Domain system key, but the system key stays the same.
How does the encryption key get stored? Can I move the disk to another Data Domain system if a head fails and
access the disk?
The encryption key is stored in multiple places on the RAID group inside the platform. Since the key is not tied to the
Data Domain system head itself, you can move the disks to another Data Domain system head and the key will be
accessible there. On a new Data Domain system head, the file system will appear locked, so you have to enter the
passphrase with the 'filesys encryption unlock' command. Moving the disk subsystem (without implicitly locking the file
system first) to a new head automatically causes the file system to be locked.
If someone pulls out a hard drive from a Data Domain system, will it be encrypted and are the keys stored on it?
A single Drive does not contain the encryption key. Encryption is on the entire Array - all disks inclusive. The Data
Domain system can be composed of a RAID group per shelf. The files system is written across ALL RAID groups. So,
you have to remove and transfer ALL the disk shelves inclusive. A single drive removed from system that is encrypted,
could not be decrypted unless it is placed back within its original RAID group.
What key management capabilities currently exist with the DD Encryption option?
Prior to DD OS 5.4, DD Encryption had very basic key management functionality. The Data Domain system has one
encryption key for all data on the system (the entire collection). The key is randomly generated when the feature is
enabled and encrypted for storage using AES 256. For reliability and security, the key is checked for corruption on every
access, and multiple copies of the encrypted key are stored in different locations on the disk (different shelves when
available) to protect against accidental key loss.
Starting with DD OS 5.4, additional functionality was added to support local encryption key management for DD
Encryption of data at rest, and support of co-existence of multiple key management options for DD Encryption on the
same DD system. Please see the DD OS 5.4 Release Notes for more information on these new features (page 17 of
linked document).
Is key rotation and key expiration functionality available?
Yes. This functionality was introduced in DD OS 5.2.
Can the key be exported or imported for vaulting purposes?
A new command was added starting with DD OS 5.3 to allow this functionality, using the "filesys encryption keys export"
command.
Is there interoperability or compatibility with any key management framework (NetApp Decru, Brocade, and EMC
RSA)?
RSA key management integration is available starting with DD OS 5.2.0.x. There are no plans for interoperability with
other products at this time.
The Encryption Passphrase
What is the passphrase?
The passphrase is a human readable (understandable) key, like a smart card, which is used to generate a
machine-useable AES 256 encryption key.
It provides two benefits:
It allows the administrator to change the passphrase without having to manipulate the actual encryption keys. Changing
the passphrase indirectly changes the encryption of the keys, but does not affect user data. Changing the passphrase
doesn't change the underlying Data Domain system encryption key. It changes the encryption of the Data Domain
system key, but the system key stays the same.
It allows a physical Data Domain system to be shipped with an encryption key on the system but without the passphrase
being stored on it. This way if the box is stolen in transit, an attacker cannot easily recover the data; instead all they can
recover is the encrypted user data and the encrypted keys.
Essentially, RSA BSAFE takes the passphrase and generates both an AES 256 encryption key and an initialization
vector, both of which are used by the AES algorithm to encrypt the system encryption key.
The passphrase is stored internally on a hidden part the Data Domain storage system. This allows for the Data Domain
system to boot and continue servicing data access without administrator intervention.
When is the passphrase used?
It is used primarily when preparing to ship or receive the Data Domain system and its external storage devices.
The process involves using the 'filesys encryption lock' command, which allows the user to lock the file system by
changing the passphrase. The user will enter a new passphrase that will re-encrypt the encryption key, but the new
passphrase is not stored. The encryption keys will not be recoverable until the file system is unlocked using the 'filesys
encryption unlock' command.
Once locked anyone who does not possess the new passphrase will not be able to decrypt the data. The Data Domain
file system won't start since the passphrase is now absent. Attempting to start the Data Domain file system will result in a
message indicating that the file system is locked and the 'filesys encryption unlock' command must be run.
Using the 'filesys encryption unlock' command requires the administrator to enter the passphrase.
Passphrase verification consists of finding the current key table from disk, decrypting the key table, and verifying the
magic number within table. Once the magic number is verified, the passphrase entered is determined to be valid and the
file system is unlocked thereby allowing the Data Domain file system to be restarted.
If the passphrase cannot be verified, the file system will not be unlocked and the Data Domain file system cannot be
started.
Since core dumps are not protected, a clean shutdown will be required after changing the passphrase. The user will be
required to delete any existing core files to protect data that may be stored in the clear.
If a passphrase changes, can data still be accessed?
Yes, changing the passphrase doesn't change the underlying Data Domain system encryption key, only the encryption of
the encryption key. Therefore, data access is not impacted.
What happens if the passphrase is lost or forgotten?
If the customer loses the passphrase while the box is locked, they will lose their data. There is no back-door or
alternative way of getting access to it. Without a good process for managing that passphrase, this could happen
accidentally and they would not be able to recover the key or data. However, the encrypted key will never be lost or
corrupted because of the system's built-in protection mechanisms.
Configuring Encryption
Which encryption commands require a Data Domain file system restart in order to take effect?
The following encryption commands require a Data Domain file system restart in order to take effect:
filesys encryption enable/disable: Globally enables/disables encryption on the Data Domain system.
filesys encryption algorithm set: Allow the user to select a cryptographic algorithm.
filesys encryption algorithm reset: Resets the encryption algorithm to AES 256 in CBC mode (the default.)
Which encryption commands require the Data Domain file system to be disabled in order to set/use them?
The following encryption commands require the Data Domain file system to be disabled in order to set/use them:
encryption passphrase change allows the user to change the system passphrase used to protect the encryption
keys.
encryption lock locks the file system (requiring a passphrase change), re-encrypts the system encryption key,
and removes the passphrase from the Data Domain system.
encryption unlock allows a user to enter a passphrase to unlock the file system.
Examples of Using Encryption:
Configuring encryption:
Add encryption license key:
sysadmin@itrdc-DD630-42# license add XXXX-XXXX-XXXX-XXXX
Added "XXXX-XXXX-XXXX-XXXX": ENCRYPTION feature
Enable encryption feature:
Note that enabling encryption will prompt for a passphrase - this must *not* be lost once set as it cannot be recovered by
Data Domain support and without the passphrase encryption configuration cannot be changed without a USB install of
the DDR which will wipe all data.
sysadmin@itrdc-DD630-42# filesys encryption enable
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The passphrase is set.
The encryption feature is now enabled.
The filesystem must be restarted to effect this change.
Restart DDFS to physically enable encryption of newly written data:
sysadmin@itrdc-DD630-42# filesys restart
Changing encryption algorithm:
# filesys encryption algorithm set {aes_128_cbc | aes_256_cbc | aes_128_gcm |
aes_256_gcm}
Note that if the algorithm is changed from the default a further file system restart is required for DDFS to start using the
new algorithm
Forcing DDFS to encryption pre-existing data after encryption is enabled:
Note that this will make the next clean cycle considerably longer/more resource intensive than normal so should only be
performed on systems with a good amount of free space otherwise the DDR could fill before cleaning completes):
sysadmin@itrdc-DD630-42# filesys encryption apply-changes
Enabling security user authorisations (this is required for use of functionality such as locking the file system
during transit):
Create a user with role security:
sysadmin@itrdc-DD630-42# user add secuser role security
Enter new password:
Re-enter new password:
Passwords matched.
User "secuser" added.
Log in as the new user and enable security user authorisations:
secuser@itrdc-DD630-42> authorization policy set security-officer enabled
Runtime authorization policy has been enabled.
Locking the file system (prior to transit of system to remote location):
Disable DDFS:
sysadmin@itrdc-DD630-42# filesys disable
Lock the file system and enter a new passphrase (note that this requires authentication by the above security user):
sysadmin@itrdc-DD630-42# filesys encryption lock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
Enter the current passphrase:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The filesystem is now locked.
Note that the new passphrase must *not* be lost/forgotten. Without this the file system cannot be unlocked meaning that
data on the DDR cannot be accessed. The only way to recover from a lost passphrase is to USB install the system losing
all data it contains.
Once complete DDFS cannot be enabled before being unlocked:
sysadmin@itrdc-DD630-42# filesys enable
Please wait....
**** There was a problem bringing up the filesystem. Status: The filesystem is disabled
and shutdown. [The filesystem is locked. Use 'filesys encryption unlock' to enter the
passphrase.]
Unlocking the file system (once system received at remote location):
Unlock the system entering the passphrase used during locking:
sysadmin@itrdc-DD630-42# filesys encryption unlock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
Enter the passphrase:
The passphrase has been verified. Use 'filesys enable' to start the filesystem.
The filesystem can now be enabled and used as normal
Disabling encryption:
Disable the encryption feature:
sysadmin@itrdc-DD630-42# filesys encryption disable
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
The encryption feature is now disabled.
The filesystem must be restarted to effect this change.
Restart DDFS:
sysadmin@itrdc-DD630-42# filesys restart
Disable security authorizations (once logged in as security user):
secuser@itrdc-DD630-42> authorization policy set security-officer disabled
Using the embedded key manager (to force automatic/periodic rotation of encryption keys):
Enable the embedded key manager:
SE@dd630-42## filesys encryption embedded-key-manager keys create
Set a key rotation period as required - the following shows setting this to 6 months (by default keys are not automatically
rotated):
SE@dd630-42## filesys encryption embedded-key-manager set key-rotation-policy 6
Note that this means a new key will be generated/made active every 6 months. This new key will only encrypt newly
written data - old data will still be encrypted using old keys
Forcibly rotating an existing key (for example if a key becomes compromised):
Generate a new encryption key:
sysadmin@dd630-42# filesys encryption embedded-key-manager keys create
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
New encryption key was successfully created.
sysadmin@dd630-42# filesys encryption keys show
Active Tier:
Key Key State Size
Id MUID post-comp
--- ---- -------------------- ----------
0.1 390 Activated-RW ** 108.00 MiB
0.3 39f Pending-Activated ** 0
--- ---- -------------------- ----------
Restart the file system to make the new key active:
SE@dd630-42## filesys encryption keys show
Active Tier:
Key Key State Size
Id MUID post-comp
--- ---- ------------ ----------
0.1 390 Deactivated 108.00 MiB
0.3 39f Activated-RW 0
--- ---- ------------ ----------
From now on newly written data will use key 0.3 however key 0.1 is kept on the system as there is 108Mb of data
encrypted using this key.
Destroy the old key - this prompts you that all old data using this key will be re-encrypted during next clean (otherwise
the corresponding data would become unreadable):
SE@dd630-42## filesys encryption keys destroy 0.1
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
** This operation will destroy the key for all of the tier/units listed below:
Tier/Unit State Size post-comp
----------- ----------- --------------
active tier Deactivated 108.00 MiB
----------- ----------- --------------
** Next filesys cleaning cycle will re-key all the data encrypted
with this key in the active tier.
Continue to destroy key [390]
Are you sure? (yes|no|?) [no]: y
ok, proceeding.
Key with MUID "390" is destroyed.
Note that the key is now marked as 'marked for destroy':
SE@dd630-42## filesys encryption keys show
Active Tier:
Key Key State Size
Id MUID post-comp
--- ---- -------------------- ----------
0.1 390 Marked-For-Destroyed 108.00 MiB
0.3 39f Activated-RW 0
--- ---- -------------------- ----------
* Post-comp size is based on last cleaning of Fri Jun 26 06:01:27 2015.
Run cleaning to re-encrypt all data using the newly activated key (note that due to having to re-encrypt existing data this
clean will take longer than a normal clean cycle):
SE@dd630-42## filesys clean start
Once complete the old key is marked as destroyed as there is no longer any data using it for encryption:
SE@dd630-42## filesys encryption keys show
Active Tier:
Key Key State Size
Id MUID post-comp
--- ---- ------------ ----------
0.1 390 Destroyed 0
0.3 39f Activated-RW 126.00 MiB
--- ---- ------------ ----------
* Post-comp size is based on last cleaning of Fri Jun 26 16:44:58 2015.
Delete the old key:
SE@dd630-42## filesys encryption keys delete 0.1
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secuser
Password:
** This operation will delete the key for all of the tier/units listed below:
Tier/Unit State Size post-comp
----------- --------- --------------
active tier Destroyed 0
----------- --------- --------------
Continue to delete key [390]
Are you sure? (yes|no|?) [no]: yes
ok, proceeding.
Key with MUID "390" is deleted.
The key is now gone:
SE@dd630-42## filesys encryption keys show
Active Tier:
Key Key State Size
Id MUID post-comp
--- ---- ------------ ----------
0.3 39f Activated-RW 126.00 MiB
--- ---- ------------ ----------
* Post-comp size is based on last cleaning of Fri Jun 26 16:44:58 2015.
Note that a DDR can hold 254 encryption keys meaning that, if rotated every six months, it would be 127 years before
the oldest encryption key was automatically removed from the system. If this were to happen, however, cleaning would
automatically re-encrypt any existing data using the removed key with the currently activated encryption key (i.e. no
manual intervention would be required in this scenario).
Clearing alerts after automatic encryption key rotation
If using the embedded key manager the following alert will appear after automatic key rotation:
Id Post Time Severity Class Object Message
--- ------------------------ -------- ---------- ------
-------------------------------------------------------------------------
207 Tue Dec 22 00:01:03 2015 WARNING Filesystem EVT-ENCRYPTION-00002: A new encryption
key has been added to the system.
--- ------------------------ -------- ---------- ------
-------------------------------------------------------------------------
There is 1 active alert.
A new key in a state of 'pending-active' will be present and DDFS must be restarted to make this active and clear the
alert
Exporting encryption keys to a text file (in case the copy on the DDR become lost or corrupted somehow):
Run the filesys encryption keys export command which prompts for details of the security user then a passphrase to use
when exporting the keys:
sysadmin@dd890# filesys encryption keys export
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
Username: secoff
Password:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
1 keys exported to file /ddr/var/.security/encryption_keys.export-2015-09-29-12-13-48
The subsequent file is created in /ddr/var/.security and is in an encrypted format, i.e.:
!!!! dd890 YOUR DATA IS IN DANGER !!!! # ls -al
/ddr/var/.security/encryption_keys.export-2015-09-29-12-13-48
-r-------- 1 sysadmin root 654 Sep 29 12:13
/ddr/var/.security/encryption_keys.export-2015-09-29-12-13-48
!!!! dd890 YOUR DATA IS IN DANGER !!!! # file
/ddr/var/.security/encryption_keys.export-2015-09-29-12-13-48
/ddr/var/.security/encryption_keys.export-2015-09-29-12-13-48: Bennet Yee's "face" format
This file should then be copied off of the DDR via FTP and stored in a safe location. To enable FTP access to the DDR
and allow a local client access:
SE@dd890## adminaccess enable ftp
FTP Access: enabled
SE@dd890## adminaccess ftp add 10.1.1.1
Security access lists updated
Note that 10.1.1.1 should be changed to reflect the IP address of an FTP client in the local environment. The file can
then be retrieved via FTP as follows (note that 10.64.102.20 should be modified to be the IP address of the DDR in the
local environment):
$ ftp 10.64.102.20
...
Name (10.64.102.20:21:binstr): sysadmin
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd .security
250 Directory successfully changed.
ftp> get encryption_keys.export-2015-11-13-12-51-33
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for
encryption_keys.export-2015-11-13-12-51-33 (654 bytes).
226 File send OK.
654 bytes received in 0 seconds (654 bytes/s)
Note that if encryption keys need to be re-imported onto a DDR EMC support would need to be engaged.
Primary Product: Data Domain
Product: Data Domain
Shared: Yes
