Beruflich Dokumente
Kultur Dokumente
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 Encryption and Key Management Solutions
Document Control
Contributors
Who Contribution
Don Peterson Author
Revision History
Version Date Changes
1.0 28th February 2013
Table of Contents
Why Encryption 1
Overview of Encryption 1
Benefits 4
Limitations 4
Performance Considerations 4
Basic Functionality 6
Benefits 6
Limitations 7
Performance Considerations 7
Key States 10
Benefits 11
Limitations 11
Performance Considerations 11
Appendices
APPENDIX A Comparison tables
APPENDIX B Related documents
ii
NetBackup Whitepaper Encryption and Key Management Solutions
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
Page 1
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 2
NetBackup Whitepaper Encryption and Key Management Solutions
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.
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
Page 3
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 4
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 5
NetBackup Whitepaper Encryption and Key Management Solutions
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
Page 6
NetBackup Whitepaper Encryption and Key Management Solutions
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
Page 7
NetBackup Whitepaper Encryption and Key Management Solutions
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.
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.
Page 8
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 9
NetBackup Whitepaper Encryption and Key Management Solutions
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.
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
Page 10
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 11
NetBackup Whitepaper Encryption and Key Management Solutions
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.
Page 12
NetBackup Whitepaper Encryption and Key Management Solutions
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
Page 13
APPENDIX A Comparison tables
The following tables compare various aspects of the different encryption solutions.
Media Server KMS Managed NetBackup
Client Encryption
Encryption Option Encryption Deduplication
Encryption target Existing tape Non-encrypted Encrypting tape Symantec
drives or disk tape drive focus drives, cloud and deduplicating
AdvancedDisk storage pool
Where is data In transit from In transit from On tape and disk In transit and on
encrypted? client and on tape media server and and in transit from disk
or disk on tape media server to
disk
Encryption Software Software Hardware or Software
software
Key store/ On each client Centralized across Centralized on N/A
manager domains master server
O/S platform All standard Solaris, Windows All major All major
support clients and Linux platforms platforms
Software cost Free Security server Free Disk Protection
and each media Optimization
server Option
Media Server
Location Client Encryption KMS Managed Encryption
Encryption Option
Key store Encryption Key (EK), checksum Public key and private Encryption key and key tag
of EK and cipher used key (KAD)
Stored on tape Checksum of EK and cipher used EK encrypted with KAD and data encrypted by
(in tar header) Public Key EK
Data encrypted by EK Has of public key
Data encrypted by EK
Stored on disk Checksum of EK and cipher used N/A KAD as attribute and data
(in tar header) encrypted by EK
Unique Per client Per backup job Per tape or disk pool
encryption key
NetBackup
Client Encryption KMS Managed Encryption
deduplication
Encryption key Per client Per segment Per storage pool
Encryption policy Per client Per host (client or Per AdvancedDisk or cloud
basis media server) storage pool
For specific country offices and Symantec Corporation Copyright 2013 Symantec
Corporation. All rights reserved.
contact numbers, please visit our World Headquarters Symantec and the Symantec logo
are trademarks or registered
Web site: www.symantec.com 350 Ellis Street
trademarks of Symantec
Mountain View, CA 94043 USA Corporation or its affiliates in the
U.S. and other countries. Other
+1 (650) 527 8000 names may be trademarks of their
respective owners.
+1 (800) 721 3934