This document is provided for informational purposes only.

All warranties relating to the information in this

document, either express or implied, are disclaimed to the maximum extent allowed by law. The information
in this document is subject to change without notice. Copyright 2013 Symantec Corporation. All rights
reserved. Symantec, the Symantec logo and NetBackup are trademarks or registered trademarks of
Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of
their respective owners




NetBackup Whitepaper
NetBackup Encryption and Key
Management Solutions
This document discusses the various options available for data
encryption in NetBackup and compares the benefits of each option.
If you have any feedback or questions about this document please
email them to IMG-TPM-Requests@symantec.com stating the
document title.
This document applies to the following versions of NetBackup: 7.0,
7.1, 7.5 and 7.6


NetBackup Whitepaper Encryption and Key Management Solutions
i

Document Control
Contributors
Who Contribution
Don Peterson Author


Revision History
Version Date Changes
1.0 28
th
February 2013


Table of Contents
Why Encryption 1
Overview of Encryption 1
NetBackup Client Encryption (CE) 3
Operation 3
Benefits 4
Limitations 4
Performance Considerations 4
NetBackup Media Server Encryption Option (MSEO) 5
Operation 5
Basic Functionality 6
Benefits 6
Limitations 7
Performance Considerations 7
NetBackup Key Management Service (KMS) 8
Operation 8
Encrypting data on tape 9
Encrypting data to Cloud Storage 9
NetBackup Whitepaper Encryption and Key Management Solutions
ii

Encrypting data to AdvancedDisk Storage 10
Key States 10
Benefits 11
Limitations 11
Performance Considerations 11
NetBackup Deduplication Encryption 12
FIPS 140-2 Validation 12

Appendices
APPENDIX A Comparison tables
APPENDIX B Related documents



NetBackup Whitepaper Encryption and Key Management Solutions
Page 1

Why Encryption
Many customers send their backup data on tape media to an off-site storage facility. When tape media
is transported from one site to another, there is the possibility of the tape being lost or stolen. If this
occurs, and confidential customer data is on those tapes, the company may have to notify all customers,
whose confidential data is at risk. This can cost a million dollars or more. Even very reputable companies
like Iron Mountain have been known to lose tapes they were transporting from a customer location to
their storage facilities.
When data is encrypted it is unreadable unless the proper key for decrypting the data is available.
Therefore, when encrypted backup tapes go missing there is no risk they can be read by unauthorized
persons. Having data encrypted avoids the need for a company to notify customers of their confidential
data being at risk if the tapes the data is on are lost. It also avoids potential lawsuits if that data was
compromised (i.e., was not encrypted) and the adverse publicity associated with the loss of confidential
data, which can also affect the companys stock price.
Industry regulations such as Sarbanes Oxley, HIPPA and PCI are also driving companies to more securely
protect confidential data.
Confidentiality of data at off-site storage, whether it is tape media sent off-site or backups to the cloud
storage, is a major security concern of most companies today. However, notebook computers often
have a great deal of proprietary information on them, whether it is customer data or internal company
data. Cell phones, tablets, and USB drives also contain company data, which is confidential. These are all
considered different end points for potential encryption.
In addition, deduplication has caused a dramatic increase in the use of disk as a backup target.
Companies often want to make a duplicate copy of that backup data at another location. Encrypting the
data while it is duplicated or replicated from one site to another site and while at rest at the second site
is gaining interest. Companies are also becoming concerned about the security of their primary storage
and are looking to encrypt that data as well.
Overview of Encryption
There are six main requirements for an enterprise level encryption and key management solution.
1. Keys for encrypting and decrypting data.
2. A key manager that is used to generate and store the keys and manage the key lifecycle process
3. A method to backup, duplicate, replicate and/or export/import keys.
4. An encryption/decryption engine. This can be in software, hardware or a combination of the
two.
5. A distribution method for providing keys from the key store to the encryption engine. For
example, the SCSI T10 spec determines how keys are passed between an application and the
tape drive.
6. A policy management engine that allows the administrator to specify which data gets encrypted.
In addition, a data/capacity reduction engine such as compression or deduplication is typically required
to minimize storage cost. Because encryption randomizes the data, if data is not compressed or
NetBackup Whitepaper Encryption and Key Management Solutions
Page 2

deduplicated prior to encryption, much more storage space would be required to store the data. This
can be software or hardware based, but must be performed prior to encrypting the data.
Two different types of encryption are commonly used.
1. Symmetric encryption the same key is used to both encrypt and decrypt the data
2. Asymmetric encryption a public/private key pair is used where the public key is used for
encryption and the private key is used for decryption
The NetBackup Client Encryption and KMS solutions both use symmetric encryption, where the same
key is used to both encrypt and decrypt the data. The encryption key is not stored on the tape or disk,
but a unique identifier to the encryption key is stored on the media. MSEO uses a combination of
symmetric and asymmetric encryption in which the same key is used to encrypt and decrypt the data.
The encryption key is encrypted by a public key and stored on the tape and decrypted by a private key in
order to be used to decrypt the data.
The NetBackup Key Management Service (KMS) allows an administrator to create keys. The KMS then
automatically generates a unique identifier for that particular key. Keys can be created using either a
random number or a pass phrase. If a pass phrase is used and a copy is stored somewhere that pass
phrase can be used to regenerate an identical key if the original key is lost. If a random number
generator is used to create a key, if that key is lost, the original key cannot be regenerated and any data
encrypted by that key cannot be restored. Realistically, electronic keys arent typically lost, but may
expire or are deleted.
Key stores are typically encrypted (keys are not stored in clear text) for security. In talking with backup
administrators for large enterprise customers, most believe their companys security organization will
specify where keys must be stored. In other words, most large companies wont want to have an
assortment of key stores for different end points.
The Key Management Interoperability Protocol (KMIP) allows integration between hosts and clients,
enabling different key management systems and/or encryption engines to communicate such that all
keys used throughout various end points could be stored (and possibly created) by a single key
management system.
When NetBackup sends keys from KMS on the master server to the media server, they are encrypted if
NetBackup Access Control (NBAC) is enabled. If NBAC is not enabled, the keys are sent in clear text.
Note: Clear-text does not mean the encryption keys are human readable. They are a binary
representation of the encryption key, which for AES would be 256 bits.
When sending keys from the key store to the encryption engine, the best security practice would be to
transmit those keys in an encrypted fashion, not in clear text. However, few customers are concerned
about the lack of encryption across FC. The SCSI T10 encryption specification has been updated to
enable encrypting the keys within the SCSI protocol and some of the new LTO6 drives will be
implementing this functionality. However, this requires the use of asymmetric encryption (public/private
key pair), which the NetBackup KMS does not support.
The policy engine for key management determines which data gets encrypted. This can be very
simplistic, such as all data being sent to a particular tape drive. However, most solutions offer some
amount of flexibility in allowing the customer different options in terms of which data gets encrypted.
This also needs to be relatively easy to configure.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 3

Because losing keys means data cannot be recovered, its very important to have a method(s) to
backup/restore or export/import the key store and encryption keys. Some solutions allow a normal
backup and restore process to be used. Other solutions provide an export/import functionality to
accomplish this or to copy keys from one key manager to another to provide redundancy and/or disaster
recovery capability.
NetBackup Client Encryption (CE)
NetBackup Client Encryption has been available for over a decade and has been enhanced with greater
encryption strengths as they have become available. It is supported on all NetBackup releases and with
all NetBackup clients other than those listed under Limitations below. It was included as part of the
standard Client license beginning with NetBackup 6.5.
By compressing data on the client, less LAN bandwidth is consumed transferring the data to the media
server. By encrypting data on the client, the confidentiality of the data is secured from the client to the
storage. Customers concerned with sending data in clear text across the LAN from the NetBackup client
to the media server should consider this solution. Data remains encrypted as it is transferred across SCSI
or FC from the media server to the storage. Client Encryption can be used to encrypt data written to
both tape and disk.
Operation
Key management for client encryption is quite basic. Each client manages its own keys, so encrypting
backups coming from a large number of clients means managing a lot of independent key files.
Keys are created via the CLI, using a pass phrase. The pass phrase should be written down (or typed) and
stored/saved somewhere, in case something happens to the key file. The keys within the key file are
encrypted. An unencrypted copy of the key file should be backed up in case the client system, where the
key file resides, dies. As long as the pass phrases used to generate the keys are known, the key file can
be regenerated if it was not backed up. Using pass phrases allows generating a key file on Client B to
restore encrypted data backed up from Client A, by creating a key using the same pass phrase. You can
also copy (or restore a backed up copy of) the Client A key file to Client B in order to restore files
encrypted by Client A to Client B. The CE software must be installed on Client B to do this.
CE uses the most recently generated key to encrypt the data, while all keys can be used for restores. A
unique identifier, based on the checksum of the encryption key and the specified cipher (e.g., AES256),
is stored in the key file and on the tape. NetBackup reads this identifier off the tape during the restore
and sends it to the client. The client matches the identifier to the appropriate encryption key and uses
the encryption key to decrypt the data.
Compression should always be performed on the client along with encryption. This is performed prior to
encryption as encryption randomizes the data and would prevent compression (or deduplication) from
reducing the amount of data to be stored. This minimizes the amount of data transferred from the client
to the media server (which frees up LAN bandwidth) as well as minimizing the amount of tape media or
disk space required.
Because CE does the compression and encryption in software, there will be additional CPU overhead
and some performance penalty when using this functionality. The CPU overhead will be related to the
amount of data being compressed and encrypted, but because most clients dont transfer huge amounts
NetBackup Whitepaper Encryption and Key Management Solutions
Page 4

of data at high speeds, impact on the overall backup process may be acceptable. The CPU overhead will
likely be something on the order of 70-80 clock cycles per byte of data being compressed and encrypted.
Compression and encryption are enabled on the Client by checking the compression and encryption
boxes in the Attributes tab of the Policy configuration screen.
CE has added greater encryption strengths over time. Today, it supports both 128-bit and 256-bit AES
encryption.
Benefits
Supported on all NetBackup releases and with all NetBackup clients other than those listed
under Limitations below
Included as part for the standard Client license beginning with NetBackup 6.5
Less LAN bandwidth is consumed transferring the data to the media server.
Confidentiality of the data is secured from the client to the drive.
Can be used to encrypt data written to both tape and disk
Keys are generated using pass phrases, so even if the key file is destroyed, as long as pass
phrases are known the key file can be regenerated.
Limitations
Not supported on NetWare and VMS clients
Not supported with BMR
Not supported with the SAN Client
Not supported with NetBackup Accelerator
Not support with Client-side deduplication
Compression and encryption performed in software, which will consume CPU cycles on the
client machine
Key management is on each client (not centralized)
Keys are only generated using pass phrases, which does not maximize security as they can be
regenerated (keys generated using a random number generator cannot be regenerated).
Performance Considerations
Client compression/encryption consumes CPU overhead, so you must make certain this overhead does
not adversely impact the applications running on the server. The fact that this overhead will also limit
performance is not a major issue if the client is sending data to a media server for backup. However, if
the client is on a SAN media server, the impact on performance could be such that it cannot keep a tape
drive streaming, which could adversely affect performance. If the backup is sent to a media server for
writing to tape, multiplexing of backup images could be used to make certain the tape drives are used
efficiently. If CE is used for backups to a VTL or to disk, the speed is of less importance unless too many
jobs are being run concurrently, resulting in a great deal of disk thrashing.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 5

NetBackup Media Server Encryption Option (MSEO)
NetBackup MSEO was released in 2007 and is a software-based solution that performs compression and
encryption on the media server. This off-loads the NetBackup client from having to perform these tasks.
Because many NetBackup clients are running applications, consuming client CPU cycles for compression
and encryption may not be desirable. MSEO moves the CPU overhead for software compression and
encryption to the media server.
There are two MSEO software components, which are separately licensed. One is the MSEO Media
Server agent, which is priced the same as a NetBackup Media Server or San Media server license on
which the MSEO agent is installed. The MSEO Media Server Agent includes a license key that must be
entered on each NetBackup media server configured with MSEO tape drives. The MSEO agent software
verifies the NetBackup MSEO license bit is enabled before it will transfer any data (encrypted or
unencrypted) to an MSEO-configured tape drive.
The second component is the MSEO Key Management Server (KMS), which is installed on what is
referred to as the MSEO Security Server.
Note: The NetBackup KMS (Key Management Service) has no relationship to the MSEO KMS. A MSEO
KMS license is NOT required to use the NetBackup KMS.
Operation
The MSEO KMS software on the Security Server provides centralized key management and the
encryption policy engine. The KMS software is installed on the Security Server, which can be a system
running NetBackup (typically this would be the master server because if the master goes down backups
and restores wont be able to performed anyway) or a completely separate system running a supported
MSEO operating system. A single MSEO Security Server can manage keys for one or many NetBackup
domains. You can also configure redundant MSEO Security Servers for high availability.
The second component is the MSEO agent, which is installed on each NetBackup media server, which
will be used to compress and encrypt backup images being written to tape. At a high level, the MSEO
media server agent includes a Virtual Tape Driver and is inserted transparently between the NetBackup
bptm daemon and the native/physical tape driver on a media server and performs compression and
encryption. Once installed, MSEO is transparent to all normal NetBackup operations, which means the
entire backup process remains the same as before installing MSEO. Compression and encryption take
place through the MSEO Virtual Tape Driver.
MSEO uses a combination of symmetric and asymmetric encryption. Initially, a Public/Private Key pair is
created. Every time a new backup job requiring encryption is run, an Encryption Key is created and sent
to the media server, where it is used to encrypt the data being backed up. The Public Key is used to
encrypt the Encryption Key, which is then written on the tape along with the encrypted data and a hash
of the Public Key. When a restore needs to be performed, the hash of the Public Key is read from tape
by the MSEO media server agent and forwarded to the MSEO Security Server. The MSEO Security Server
uses the Public Key hash to determine which Public Key was used for encrypting the Encryption Key. It
then sends the corresponding Private Key (from the Public/Private Key pair) to the MSEO media server
agent. The MSEO media server agent uses the Private Key to decrypt the Encryption Key, and then uses
the Encryption Key to decrypt the data before sending on the data to the bptm daemon. The encrypted
Encryption Key is stored only on the tape, not in the MSEO Security Server.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 6

MSEO provides a variety of compression and encryption algorithms to use. These can be specified using
Key Words in the in the Attributes tab of the NetBackup Policy configuration screen or by defining them
in rules configured through the MSEO Security Server Console.
MSEO provides an Export/Import feature to copy keys from one MSEO Security Server to another MSEO
Security Server. This can be a subset of the keys within the MSEO Security Server. The Export/Import
feature of MSEO can also be used to backup the Security Server. You can use NetBackup to backup the
appropriate directories and files used in the Export operation. However, the Import operation requires
files be put in a different directory, so you CANNOT use a standard NetBackup restore operation to
rebuild the Security Server. There are some manual operations that are covered in the MSEO System
Administration Guide. If you attempt to use a standard NetBackup restore operation to rebuild a MSEO
Security Server, it will corrupt the keys and you will not be able to restore any backup images previously
encrypted.
Because MSEO performs compression and encryption in software, there must be enough CPU cycles
available to obtain acceptable performance. In analyzing the impact of MSEO on the media server, a
ballpark estimate indicates roughly 70-90 CPU cycles are required per BYTE of data backed up on
Windows/Linux and UNIX media servers respectively.
Basic Functionality
Initially supported on NetBackup 5.1 MP3 and was supported on all NetBackup 6.0 and 6.5
versions. Now supported on all NetBackup 7.x versions
Supports encrypting backups to most physical tape drives supported by NetBackup (see
NetBackup HCL for specifics) and VTLs
Supports encrypting backups to most tape drives
Supported on Solaris 9 and 10 SPARC and x64, Red Hat Linux 4 and 5, SUSE 10 and 11, Windows
2003 x86 and x64 and Windows 2008 x64
MSEO Key Management Software can be installed on a NetBackup system (typically master
server) or a completely separate system. This software/system is referred to as the MSEO
Security Server.
OpenSSL is used to encrypt communication and keys transferred between MSEO media server
agents and the MSEO Security Server
MSEO Security Server Console allows configuring encryption policies
Benefits
Off-loads NetBackup client from having to perform compression and encryption
Security Server can manage keys for multiple NetBackup domains
Export/Import feature for Key Management allows easily duplicating all keys (or a subset) to a
second Security Server to provide redundancy and high availability
Much granularity in specifying which data is compressed and encrypted
MSEO media server agent is FIPS 140-2 certified
NetBackup Whitepaper Encryption and Key Management Solutions
Page 7

Limitations
Cannot use standard NetBackup backups and restores for protecting the keys; you must use the
Export/Import functionality of MSEO
Must have a enough CPU cycles on media server(s) to handle the amount of data being backed
up
Because MSEO compresses the data, it may be difficult to keep the newer, fast tape drives
streaming even at their minimum date rate unless the media server has enough CPU GHz to
support the drives data rates.
Not supported on AIX and HP-UX OS platforms and no plans to do so.
Transparent to NetBackup, so verifying what has been encrypted must be performed through
MSEO.
Performance Considerations
The MSEO driver is multithreaded and the software has been tuned for multiple drive environments to
be able to utilize all of the multiple CPUs processing power.
However, with faster tape drives, you can easily run into a CPU bottleneck if you dont carefully analyze
the backup environment. It takes roughly 70 more clock cycles on a Windows or Linux server or about 90
more clock cycles on UNIX server to perform MSEO compression/encryption per BYTE of data backed
up. Backing up 100 MB/sec of data through a Solaris media server requires about 9 GHz of CPU
processing for MSEO, plus whatever processing is needed for other tasks.
Although the number of clock cycles used for regular, unencrypted backups may vary from media server
to media server this represents a significant increase in all cases. Deploying MSEO on an existing
infrastructure may result in the throughput dropping dramatically and it may be necessary to reduce the
number of tape drives per media server and deploy additional media servers to achieve the same
throughput. Adding HBAs to a media server to get additional throughput doesnt just work when
software compression/encryption is used.
To determine the impact of deploying MSEO encryption, first determine how much data must be backed
up and the length of the backup window. This determines the minimum required sustained data rate to
complete the backup in the allotted time frame. Allow an additional 10% for tape mounts and load
times. Multiplying that data rate in GB/sec by 70 or 90 CPU cycles/byte determines the CPU GHz
required for MSEO compression/encryption. For example, if the backup window is 8 hours and the
amount of data to be backed up is 2.5 TB, the sustained data rate is around 91 MB/sec. Allowing for
tape mounts and load times raises this to around 100 MB/sec, requiring between 7 GHz and 9 GHz of
CPU on the media server depending on the operating system used.
While smaller volumes of data and longer backup windows may require less CPU cycles, it is also
important to consider the tape technology being used. All tape drives have a minimum data rate at
which they must receive data in order to keep the media streaming. If the incoming data rate drops
below the minimum speed, the drive will stop the media, rewind it to the proper location, then resume
the data transfer to the media. This stop, rewind, restart process is referred to as shoe-shining and
adversely impacts overall data throughput.
You must take into account how much MSEO is able to compress the data. For example, if MSEO can
compress the data 2:1, and the minimum streaming speed of a tape drive is 30 MB/sec, MSEO will need
NetBackup Whitepaper Encryption and Key Management Solutions
Page 8

to compress and encrypt data at 60 MB/sec to keep the tape steaming. This means a minimum of 4.2
GHz of CPU for Windows or Linux 5.4 GHz of CPU for UNIX for each tape drive, just to keep the drive
streaming at its minimum rate, which still isnt using the tape drive efficiently.
For IBM LTO tape drives, Digital Speed Matching (to maintain streaming operation) is provided at
specific transfer rates, with the minimum being 50% of the native rate for LTO2 and LTO3 drives, 28% for
LTO5 drives and 25% for LTO4 and LTO6 drives.
For HP LTO tape drives, the drive can maintain streaming down to 1/3 the native transfer rate. HP refers
to this as data rate matching. Below that limit, the drive will stop streaming. Between the upper and
lower limits, the drive will adjust performance automatically, on-the-fly.
One way to reduce MSEOs CPU impact is to use the NetBackup client to perform the compression. This
will obviously impact the client CPU, but if there is available bandwidth on the client, it would likely
reduce the MSEO overhead by about 60%. Compressing the client data also means less data will be sent
across the LAN from the client to the media server freeing up LAN bandwidth.
In summary, using faster tape drives and making efficient use of them requires adequate CPU GHz in the
media server.
A MSEO performance calculator is available and provides performance estimates based on OS platform,
number of CPUs/cores and speed, tape drive vendor and drive type, number of tape drives per media
server and amount of data to be backed up.
NetBackup Key Management Service (KMS)
The NetBackup Key Management Service (KMS) was introduced in the NetBackup 6.5.2 release and
initially managed encryption keys for tape drives supporting the SCSI T10 encryption standard. Today,
this includes all LTO4, LTO5 and LTO6 tape drives, IBM TS1120/30/40 tape drives and Oracle T10000B/C
tape drives.
The key store for KMS is located on the master server and manages keys within a single NetBackup
domain. The Key Store can be installed on any OS platform supported by NetBackup as a master server.
Any OS platform supported by NetBackup as a media server can be used to backup data to one of the
supported tape drives. The KMS is included with the Enterprise Server and Server licenses and is no
additional charge.
In NetBackup 7.1, an OST encryption plug-in was added to the NetBackup media server. The OST plug-in
obtains keys from the NetBackup KMS to encrypt data (using AES256 encryption) being sent to cloud
storage pools. In NetBackup 7.5, this same encryption capability was added for backups to AdvancedDisk
storage pools.
Operation
The NetBackup KMS runs on the master server and manages encryption keys for tape drives with
embedded encryption and the NetBackup OST plug-in encryption engine. The Key Store on the master
server contains Key Records. Each Key Record consists of an encryption key, a unique identifier for that
key, and metadata (e.g., date key was created, status of the key, description for the key, etc.). All
encryption keys in the Key Store are encrypted with a Key Protection Key (KPK) and the entire Key Store
is encrypted with a Host Master Key (HMK). Both of these keys are AES256.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 9

The Key Store is initially created using the NetBackup CLI. The administrator is then requested to enter
either a pass phrase or allow a random number generator to be used to create the Host Master Key. An
additional request is made to create the Key Protection Key. It is recommended that these two keys be
created using pass phrases. That way, if these keys are lost, both keys can be recreated to decrypt the
KMS Key Store.
When a cloud storage pool is being created, a wizard pops up and allows the initial creation of the KMS
key store if it has not already been created. This includes generating the HMK and KPK keys, and a key
group and encryption key for the cloud storage pool. More details on this can be found in the Encrypting
data to Cloud Storage section of this document.
Encrypting data on tape
Once a key store has been created, a Key Group is then created using the NetBackup CLI. When used
with tape, the Key Group must have an ENCR prefix. Because NetBackup will use the tape drive to
encrypt any data written to media in a volume pool with an ENCR prefix, a NetBackup volume pool must
be created with the name matching the Key Group name. Once this is completed, the NetBackup CLI is
used to create an encryption key. A pass phrase or random number can be used to generate encryption
keys, like is done for the KPK and HMK. Once the encryption key has been created, NetBackup generates
a Key Tag (256 bits, 64 characters), which is the unique identifier for that encryption key. If a pass phrase
is used for the encryption key, as long as the pass phrase and key tag are known, an identical encryption
key can be created in case something happens to the Key Store or encryption key.
Note: When a random number generator is used to generate an encryption key, if the key is lost or
deleted, data encrypted by that key can NEVER be restored.
The SCSI T10 encryption standard requires a KAD (Key Associated Data), which is a unique identifier for
an encryption key, to be written on the tape along with the encrypted data. NetBackup uses the Key Tag
as this unique identifier if the tape drive supports a 256-bit KAD; otherwise the key Tag is truncated to
the appropriate length.
When the backup image is to be encrypted, the NetBackup media server obtains the active encryption
key and KAD for the volume pool being used (which has a corresponding Key Group) from the master
server. The media server sends the encryption key, KAD and data to the tape drive, which uses the
encryption key to encrypt the data and also writes the KAD onto the tape.
If this backup image or individual files need to be restored, the NetBackup media server requests the
KAD from the tape drive and sends this to the KMS on the master server. The KMS looks up the
encryption key corresponding to the KAD and sends this to the media server, which passes it to the
drive. The drive then uses the encryption key to decrypt the data and send it to the media server.
Encrypting data to Cloud Storage
The KMS can be used along with the OST encryption plug-in on the media server to encrypt data going
to cloud storage. Each Cloud storage target used for NetBackup storage requires a key group. KMS
requires a unique name for each key group, using the format: cloud_provider_url:volume_name. For
example, nirvanix.com:filesystembackups
When configuring cloud storage, the cloud_storage_server_stype defines the storage type and storage
vendor. The vendor is the name of the cloud provider. The storage type is either encrypted or not
NetBackup Whitepaper Encryption and Key Management Solutions
Page 10

encrypted. For example use nirvanix_raw to not encrypt the data and nirvanix_encrypt to encrypt the
data.
If the Key Management Service (KMS) is not already configured, the Cloud Storage Server Configuration
Wizard includes steps to create and enable KMS. The command line can also be used to configure KMS.
When adding (configuring) cloud volumes, the option of using a single pass phrase (a single encryption
key) for each volume or the same pass phrase for all volumes must be selected. Depending on the
option chosen, a pass phrase will need to be entered when adding only the first volume or when each
volume is added.
Cloud storage can also be configured using the nbdevconfig command. More detail on this can be
found in both the NetBackup Cloud Administrator Guide and the NetBackup Commands Reference
Guide.
The NetBackup Security and Encryption Guide has a great deal of additional information on the
NetBackup KMS in the chapter titled Data at rest key management.
Encrypting data to AdvancedDisk Storage
The NetBackup KMS can be used along with the OST encryption plug-in on the media server to encrypt
data going to AdvancedDisk storage.
To use encryption, the AdvancedDisk_crypt type must be used when configuring the storage servers and
the disk pools. The nbdevconfig command must be used to configure the storage servers and the
disk pools.
Each storage server and volume combination requires a key group. The key group name is of the
following format: storage_server_name:volume_name. The volume_name must be the last directory
name in the pathname to the volume.
More details can be found in the NetBackup AdvancedDisk Storage Solutions Guide. The NetBackup
Security and Encryption Guide has a great deal of additional information on the NetBackup KMS in the
chapter titled Data at rest key management.
Key States
The NetBackup KMS supports a number of states for encryption keys. When encryption keys are created
they can be put into a Prelive or Active state. In an Active state, the encryption key will be used for any
backup jobs specifying that volume pool or name. The Prelive state would be used if a customer wants
to periodically change keys. A script could be written that automatically changes an encryption key in a
Prelive state to the Active state. When a new key is moved to an Active state, the existing key is moved
to an Inactive state. A key in an Inactive state is only used for restores. An encryption key can also be
moved to a Deprecated state. In this state it cannot be used for either backups or restores. This might be
done to prevent restoring specific backup jobs without some type of approval. Encryption keys can be
moved between Active, Inactive and Deprecated states. The final state is called Terminated, in which the
encryption key is placed to delete the key. Once the key is deleted, no data encrypted with that key can
be restored unless a pass phrase was used to generate the encryption key and both the pass phrase and
the Key Tag are a known.
The NetBackup KMS should be backed up. It is not part of the NetBackup catalog backup, but it would
be wise to backup the three KMS files with the catalog. A KMS backup consists of three files: the KMS
NetBackup Whitepaper Encryption and Key Management Solutions
Page 11

database, the HMK file and the KPK file. The KMS database should be backed up to a different tape than
the HMK and KPK files; otherwise someone obtaining the tape would have access to all the encryption
keys. You should not encrypt the backup of the KMS files as this is the equivalent of locking the keys in
the safe and modern cryptography doesnt allow picking the lock. Before being backed up, the KMS
database should be quiesced using the NetBackup CLI. It can be unquiesced once the backup is
completed. Because the database only changes when Key Groups or encryption keys are created or
attributes are changed, quiescing the database does not affect the ability to encrypt backup jobs or
restore encrypted backup images.
The Key Store can be copied from one master server to another by using a backup/restore operation or
just copying the three files.
Benefits
Centralized Key Store for a NetBackup domain
Compression and encryption performed by tape drive, so no performance degradation or impact
on media server CPU
Encrypts data to cloud and AdvancedDisk storage pools
Free functionality with NetBackup 6.5.2 and later
KMS can be used on all supported NetBackup master server platforms and all supported media
server platforms can write to encrypted tape drives
Limitations
Maximum of 20 Key Groups (ability to encrypt a total of 20 volume and/or disk pools) with 10
encryption keys per group (note: In NetBackup 7.6, a maximum number of 100 key groups will
be supported.)
No export/import functionality
All management performed via NetBackup CLI unless Cloud storage is the backup target
Encryption keys encrypted when transferred from master server to media server only if
NetBackup Access Control (NBAC) is used
OST encryption plug-in supports on encryption, not compression and will consume some CPU
overhead for encrypting data cloud or AdvancedDisk storage pools.
Performance Considerations
Unlike MSEO, because compression and encryption are performed in hardware on the tape drive; using
KMS does not result in performance degradation or CPU overhead on the media server.
For encryption to Cloud or AdvancedDisk storage, AES256 encryption is performed in software on the
media server. This is likely to consume about 30 clock cycles per byte of data being encrypted, so that
needs to be taken into account and to make certain there enough CPU processing power on the media
server to handle the maximum data rate expected.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 12

NetBackup Deduplication Encryption
The various NetBackup deduplication methods, which include PDDO, MSDP and client-direct, all utilize
the same encryption functionality.
Blowfish 128-bit encryption is used with all of these deduplication methods. The 128-bits are combined
with a 128-bit hash to generate a 256-bit key, which is used for encrypting the data. Encryption keys are
automatically generated for each unique data segment.
By default, deduplication encryption is disabled, however, Symantec recommends that you use
deduplication encryption.
The following is the behavior for the encryption that occurs during the deduplication process:
If you enable encryption on a client that deduplicates its own data, the client encrypts the data
before it sends it to the storage server. The data remains encrypted on the storage.
Data is transferred from the client over a Secure Sockets Layer to the server regardless of
whether or not the data is encrypted. Therefore, data transferred from clients that do not
encrypt their own data is also protected across the LAN.
If you enable encryption on a load-balancing server, the load-balancing server encrypts the data.
It remains encrypted on storage.
If you enable encryption on the storage server, the storage server encrypts the data. It remains
encrypted on storage. If the data is already encrypted, the storage server does not encrypt it.
Encryption is enabled on either the media server or client via the NetBackup CLI.
You can enable encryption on all hosts that deduplicate their own data without configuring them
individually or you can enable encryption on individual hosts.
Keys are not managed as they are with CE, MSEO or the NetBackup KMS. This is because the
deduplication software automatically generates keys for each new segment that is backed up (if
encryption is enabled).
Specifics regarding Enabling deduplication encryption can be found in the section of that name,
beginning on page 87 of the Symantec NetBackup Deduplication Guide.
FIPS 140-2 Validation
The National Institute of Standards and Technology (NIST) FIPS is concerned with Information
Technology security and has a Cryptographic Module Validation Program (CMVP) and allows vendors to
obtain various levels of FIPS 140-2 validation for their cryptographic modules. Validation requires
modules to use NIST approved cryptographic algorithms, hashes and random number generators.
Vendors also specify the boundary of their implementation. Most validations for NetBackup would be
for FIPS 140-2 Level 2 unless the NetBackup appliance were to be validated, which would be at a Level 3.
When this document was written, only the MSEO 6.1.0 media server drive (agent) had
received FIPS validation. The NIST validation can be found at the following URL:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm
If you scroll down to Cert # 1057 on that page (they are in descending order), you will find the
Vormetric listing for the MSEO driver. We license the MSEO software from Vormetric.
NetBackup Whitepaper Encryption and Key Management Solutions
Page 13

In order for NetBackup to run in a FIPS 140-2 mode, the cryptographic primitives used in NetBackup
client encryption, the NetBackup KMS, the OST encryption plug-in (used to encrypt data going to Cloud
or AdvancedDisk storage pools) and NBAC will be updated use a crypto module that Symantec will have
FIPS validated. This will result in a FIPS 140-2 validation certificate for Symantec for this crypto module.
The following tape drives, which provide encryption, have received FIPS validation:
Vendor Tape Drive NIST Certificate #
HP LTO-5 1486
IBM LTO-4 1152
IBM LTO-5 1522
Oracle T10000A 1157
Oracle T10000B 1156
Oracle T10000C 1561
Table 1 - FIPS validated tape drives
In addition to the crypto primitive, FIPS validation also considers hashes used (e.g., MD5 cannot be used,
but SHA-2 can be) and the use of a FIPS validated random number generator when generating
encryption keys (FIPS does not allow the use of only a pass phrase when generating encryption keys).
Because FIPS validation is performed on a specific version of hardware or software and on a specific
operating system platform, if the version of hardware or software is changed or the operating system
platform is changed, a previous validation does not apply to a newer version of the hardware or
software.
Therefore, because any change to NetBackup, such as a new maintenance release, would cause
NetBackup to no longer be considered FIPS validated, we are not planning to validate NetBackup as a
whole. What we plan to do is validate the cryptographic module used within NetBackup.
We are working on updating NetBackup to use the updated crypto module and to enable NetBackup to
run in FIPS mode. The initial implementation of FIPS mode will be for the NetBackup KMS with the
conversion of other areas of NetBackup to FIPS mode in subsequent releases. The current process for
getting FIPS validation takes about eight months, but once that process is underway (we will get a letter
from the testing facility verifying that), NetBackup should be acceptable to customers from a FIPS
validation standpoint.
NetBackup deduplication (PureDisk, MSDP and client direct deduplication) uses Blowfish 128 encryption,
which is not a cryptographic primitive that can obtain FIPS validation. It has not yet been decided
whether we will modify the deduplication software to obtain FIPS validation.
We are considering getting the NetBackup Master/Media server appliance FIPS validated in the future.
Customers have been using NetBackup to encrypt data for many years and this has included generating
keys using pass phrases and using crypto primitives that cant obtain FIPS validation. NetBackup wont
prevent customers from using pass phrases to create a key because they may need to recreate an older,
non-FIPS key in order to recover old data created with that key.


APPENDIX A Comparison tables
The following tables compare various aspects of the different encryption solutions.
Client Encryption
Media Server
Encryption Option
KMS Managed
Encryption
NetBackup
Deduplication
Encryption target Existing tape
drives or disk
Non-encrypted
tape drive focus
Encrypting tape
drives, cloud and
AdvancedDisk
Symantec
deduplicating
storage pool
Where is data
encrypted?

In transit from
client and on tape
or disk
In transit from
media server and
on tape
On tape and disk
and in transit from
media server to
disk
In transit and on
disk
Encryption Software Software Hardware or
software
Software
Key store/
manager
On each client Centralized across
domains
Centralized on
master server
N/A
O/S platform
support
All standard
clients
Solaris, Windows
and Linux
All major
platforms
All major
platforms
Software cost Free Security server
and each media
server
Free Disk Protection
Optimization
Option
Table 2 - Key selection criteria

Location Client Encryption
Media Server
Encryption Option
KMS Managed Encryption
Key store Encryption Key (EK), checksum
of EK and cipher used
Public key and private
key
Encryption key and key tag
(KAD)
Stored on tape

Checksum of EK and cipher used
(in tar header)
Data encrypted by EK
EK encrypted with
Public Key
Has of public key
Data encrypted by EK
KAD and data encrypted by
EK
Stored on disk Checksum of EK and cipher used
(in tar header)
N/A KAD as attribute and data
encrypted by EK
Unique
encryption key
Per client Per backup job Per tape or disk pool

Table 3 - What gets stored where?





Key management Encryption
Client Run bpkeyutil command to
create key file and pass phrase
Specify encryption attribute in policy (also
enable compression for tape backups)
Media Server
Encryption Option
Create key pairs and encryption
policies
Configure MSEO tape drives on media
servers
KMS Tape Create KMS db, key groups and
keys using CLI
Create volume pool with ENCR suffix
matching key group name
KMS Cloud Use wizard to create KMS db and
encryption key
Use wizard to create Storage Server and
Storage Poll for encryption
KMS AdvancedDisk Create KMS db, key groups and
keys using CLI
Use nbdevconfig to create Storage
Server and Storage Poll for encryption
NetBackup
Deduplication
None Enable via pd.conf on each host
Table 4 - Key management encryption configuration

Client Encryption
Media Server Encryption
Option
KMS Managed Encryption
Encryption key Per client Per backup job Per volume pool
Encryption policy
basis

Per backup policy Various options including
backup policy, client, media
id, copy # and volume pool.
Per volume pool
Encryption (and
compression)
performed in:
Software Software Hardware
Table 5 - Encryption on tape

Client Encryption
NetBackup
deduplication
KMS Managed Encryption
Encryption key Per client Per segment Per storage pool
Encryption policy
basis

Per client Per host (client or
media server)
Per AdvancedDisk or cloud
storage pool
Encryption (and
compression)
performed in:
Software Software Software
Table 6 - Encryption on disk



Table 7 Using Encryption and Key Management with NDMP
The NDMP spec does not support backups to disk from a NAS host, which is why there is an x in many
cells.
MSEO can only be used when the data path is through the NetBackup media server, which means remote
NDMP must be used.
KMS can also be used with:
Quantum VTLs supporting NDMP DirCpy functionality
OST Storage Servers listing Direct_Copy and KMS as supported functionality. As of the publication
date, this included various Quantum and Fujitsu OST devices
Refer to the NetBackup Hardware Compatibility List for updated information


Direct Attach /
Local
3-way (from one NAS
host to another)
Remote (thru
media server)
Encrypted tape drive NBU KMS NBU KMS NBU KMS
Tape drive w/o encryption or
drive encryption not used
x x MSEO
VTL x x MSEO
AdvancedDisk x x NBU KMS
Symantec Dedupe storage x x Built-in
Cloud Storage x x NBU KMS


APPENDIX B - Related Documents and Hyperlinks
A MSEO Performance Calculator is available and provides performance estimates based on number of media
servers; operating system; number and GHz of CPUs/Cores; % of CPU already used; number of tape drives,
model and vendor; amount of data to be backed up and compressibility of the data.
https://symiq.corp.symantec.com/departments/pm/nbu/Pages/EncryptionandSecurity.aspx
The above is an internal web site, so you may need to ask a Symantec Sales Engineer to provide this to you.
NetBackup Security and Encryption Guide Has great deal of additional information on the NetBackup
KMS in the chapter titled Data at rest key management
NetBackup Cloud Administrator Guide
NetBackup AdvancedDisk Storage Solutions Guide
Symantec NetBackup Deduplication Guide
NetBackup Commands Reference Guide
How to Export and Import Encryption Keys Using the NetBackup KMS



About Symantec:

Symantec is a global leader in
providing storage, security and
systems management solutions to
help consumers and organizations
secure and manage their
information-driven world.
Our software and services protect
against more risks at more points,
more completely and efficiently,
enabling confidence wherever
information is used or stored.


For specific country offices and
contact numbers, please visit our
Web site: www.symantec.com

Symantec Corporation
World Headquarters
350 Ellis Street
Mountain View, CA 94043 USA
+1 (650) 527 8000
+1 (800) 721 3934

Copyright 2013 Symantec
Corporation. All rights reserved.
Symantec and the Symantec logo
are trademarks or registered
trademarks of Symantec
Corporation or its affiliates in the
U.S. and other countries. Other
names may be trademarks of their
respective owners.