Oracle Database Integration Guide TDE... · 2020. 8. 3. · Page 2 of 98 Oracle Database -...

Oracle DatabaseIntegration Guide Unix/Windows

Version: 1.27

Date: Friday, September 11, 2020

Copyright 2020 nCipher Security Limited. All rights reserved.

Copyright in this document is the property of nCipher Security Limited. It is not to be reproduced,modified, adapted, published, translated in any material form (including storage in any medium byelectronic means whether or not transiently or incidentally) in whole or in part nor disclosed to any thirdparty without the prior written permission of nCipher Security Limited neither shall it be used otherwisethan for the purpose for which it is supplied.

Words and logos marked with ® or ™ are trademarks of nCipher Security Limited or its affiliates in the EUand other countries.

Mac and OS X are trademarks of Apple Inc., registered in the U.S. and other countries.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in theUnited States and/or other countries.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Information in this document is subject to change without notice.

nCipher Security Limited makes no warranty of any kind with regard to this information, including, but notlimited to, the implied warranties of merchantability and fitness for a particular purpose. nCipher SecurityLimited shall not be liable for errors contained herein or for incidental or consequential damagesconcerned with the furnishing, performance or use of this material.

Where translations have been made in this document English is the canonical language.

of 63 Oracle Database - Integration Guide Unix/Windows

Contents

1 Introduction 6

1.1 This Guide 6

1.2 Product configuration 7

1.3 Conventions used in this document 7

1.3.1 Multitenant and non-multitenant 7

1.3.2 Database connections 8

1.3.3 Key migration and legacy keys 9

1.3.4 Paths used 10

2 Overview 11

3 Installation and configuration 12

3.1 Preparatory requirements 12

3.2 Basic setting up 13

3.3 Installing in an Oracle RAC configuration 16

4 Configuring and Using nCipher Encryption Facilities 18

4.1 Configuring Oracle database software to use the nCipher HSM 18

4.2 Opening and closing a keystore or HSM 19

4.3 Migrating from software wallet to HSM (non-multitenant) 20

4.3.1 Using the sqlnet.ora file 20

4.3.2 Using the WALLET_ROOT and TDE_CONFIGURATION parameters 21

4.4 Migrating from software keystore to HSM (multitenant) 21



4.5 Create master keys directly in a HSM for non-multitenant database 24



4.5.3 Create the encryption keys 25

4.6 Create master keys directly in a HSM for multitenant database 25



4.6.3 Create the CDB and then all PDB master keys in one operation 26

4.6.4 Create the CDB master key and a single PDB master key 27

Oracle Database - Integration Guide Unix/Windows of 63

4.6.4.1 Create the CDB master key: 27

4.6.4.2 Create a single PDB master key: 27

4.7 Rekeying or key rotation 27

4.7.1 Rekey when sharing keys between clients 28

4.7.2 Rekey for a non-multitenant database 29

4.7.3 Rekey for a multitenant database; CDB and all the PDBs in one operation 29

4.7.4 Rekey for a multitenant database; CDB only 29

4.7.5 Rekey for a multitenant database; single PDB only 29

4.7.6 Rekey in a RAC cluster 29

5 Troubleshooting 31

Appendix A Security Worlds, key protection, and failure recovery 34

Appendix B Cluster configuration suggestions 37

B.1 Oracle RAC configuration using nShield Solos 37

B.2 Oracle RAC configuration using nShield Connects 38

B.3 Common Security World on RFS 39

B.3.1 Implementing the Common Security World on RFS configuration 40

B.4 Common Security World on shared disk 42

B.4.1 Implementing the Common Security World on shared disk configuration 43

Appendix C Setting up a remote shared folder 46

C.1 Where the remote server is UNIX/Linux based 46

C.2 Where the remote server is Windows based 46

C.3 Where the local client is UNIX/Linux based 47

Appendix D About the HSM credential 49

D.1 Change passphrase only 51

D.2 Change token with associated passphrase but keep same protection method 52

D.3 Change protection method 53

Appendix E Latency issues 55

E.1 Storage and distribution of updated master keys 55

E.1.1 Common storage of master encryption keys 55

E.1.2 Local storage of master encryption keys 56

E.1.3 Making a hardserver instance recognize new master keys 57

E.1.4 Other considerations 57


Appendix F How Oracle works with the nShield HSM 59

Contact Us 62

Europe, Middle East, and Africa 62

Americas 62

Asia Pacific 62


1 Introduction

1 IntroductionThis guide describes how to integrate and use nCipher Security World software and nCipher SecuritynShield Hardware Security Modules (HSMs) with an Oracle database. The Oracle feature TransparentData Encryption (TDE) provides data-at-rest encryption for sensitive information held by the Oracledatabase, while at the same time allowing authorized clients to use the database as normal. Bothmultitenant and non-multitenant Oracle database types are supported.

Oracle database software, and nCipher Security World software with nShield HSMs, can beindependently installed on the same host server. They can then be configured to interoperate through asingle library interface that requires very little setup. It is possible to support multiple database instanceson the same host server, while each database instance is restricted to access only its own encryptionkeys. Oracle cluster technology can also be supported.

Integrated Oracle and nCipher technology has been tested to support Oracle TDE for tablespaceencryption, for column encryption, and concurrently for both. nCipher nShield HSMs are certified to FIPS140-2 (level 3) to deliver a high grade of security assurance. Functionality includes protection of sensitiveencryption keys and support for offload of encryption and key management operations.

1.1 This GuideThis Integration Guide covers UNIX/Linux and Windows based systems.

It provides:

l An overview of how the Oracle database software and nCipher Security World software with HSMmay work together in order to enhance security

l Configuration and installation instructions

l Depending on your current Oracle setup, how to:o Migrate encryption from an existing Oracle wallet or keystore to HSM protectiono Begin using HSM protection immediately if no Oracle software wallet or keystore already

exists

l Examples and advice on how the product may be used

l Troubleshooting advice.

It is assumed the reader has a good knowledge of Oracle database technology.

Assuming you already have your Oracle database installed, after installing and configuring the nCipherSecurity World software with the HSM, there is no other software required. However, some minorconfiguration changes will be needed.

You can find the installer and all the associated configuration files and executable for the nCipherSecurity World software on the supplied installation media. This should also include copies of the UserGuides you may need to reference in order to use the nCipher software and HSM.

This guide cannot anticipate all configuration requirements a customer may have. Examples shown inthis guide are not exhaustive, and may not necessarily show the simplest or most efficient methods of


1 Introduction

achieving the required results. The examples should be used to guide integration of the nCipher HSMwith an Oracle database, and should be adapted to your own circumstances.

nCipher Security accepts no responsibility for loss of data, or services, incurred by use of examples, orany errors in this guide. For your own reassurance, it is recommended you thoroughly check your ownsolutions in safe test conditions before committing them to a production environment. If you requireadditional help in setting up your system, contact nCipher Support, seehttps://www.ncipher.com/services/support/contact-support.

nCipher Security accepts no responsibility for information in this guide that is made obsolete by changesor upgrades to the Oracle product.

This guide assumes that you have read the Security World and HSM documentation, and are familiar withthe documentation and setup processes for Oracle database TDE.

1.2 Product configurationThe integration has been successfully tested in, and is supported for, the following configurations:

Operating System Oracle DB nShield HSM nShield Software

Red Hat Enterprise Linux 7.8 19.5.0.0.0 Solo, Solo +, Solo XCConnect, Connect +, Connect XC

12.60.11

Windows Server 2016 Datacenter 12.2.0.1.x Solo, Solo +, Solo XCConnect, Connect +, Connect XC

12.60

Oracle Linux 7.2 12.2.0.1.x Solo, Solo +, Solo XCConnect, Connect +, Connect XC

12.50.4


12.40.2


12.40.2

1.3 Conventions used in this document

1.3.1 Multitenant and non-multitenant

Descriptions in this Integration Guide may cover non-multitenant databases and multitenant databases.Oracle terminology used for each type of database appears to be diverging. This guide will attempt to usethose terms appropriate to the database type under discussion, as outlined:

l Non-multitenant databases are Oracle version 11g or earlier. Multitenant databases start fromOracle version 12c.

l Non-multitenant database software can only create and use non-multitenant databases. If non-multitenant databases are the subject matter, we will use the non-multitenant and SQL terminologyas shown below.


https://www.ncipher.com/services/support/contact-support

1.3.2 Database connections

l Database software supporting multitenant databases may also optionally support non-multitenantdatabases. In this case, if a non-multitenant mode is the subject matter, then we will use the non-multitenant terminology and SQL shown below. If a multitenant mode is the subject matter, thenwe will use the multitenant terminology and SQL.

Non-Multitenant (non-container) Multitenant (container)

Terminology for Oracle software based encryption key repository

Software wallet Software keystore

SQL preamble for encryption related commands

ALTER SYSTEM SET ENCRYPTION etc ADMINISTER KEY MANAGEMENT etc

Where such terminology applies equally to a software wallet or software keystore, the defaultterminology software keystore is used to cover both descriptive instances.

1.3.2 Database connections

You must be a user with correct permissions to access a database, and also have the correct privilegesto perform the required operations when connected to that database. Your system administrator shouldbe able to create users and grant suitable permissions and privileges according to your organization’ssecurity policies.

In this document, making a database connection will be denoted by the following syntax:

CONNECT <database-user>@<database-identifier>

l <database-user> is the user identity making the connection

l <database-identifier> is the database to make the connection to.

For the purpose of examples in this guide, the following database users and database identifiers shouldbe sufficient.

Non-multitenant <database-user> will usually be one of:

l sysdba, Oracle’s standard sysdba user

l system, Oracle’s standard system user

l TESTER, as a local user.

Non-multitenant <database-identifier> will be:

l DB, in practice usually the ORACLE_SID of the database. For example:

CONNECT sysdba@DB

CONNECT TESTER@DB

For multitenant databases:


1 Introduction

l CDB<n> indicates a container database where <n> is a distinguishing digit.

l PDB<k> indicates a pluggable database where <k> is a distinguishing digit.

Multitenant <database-user> will usually be one of:

l sysdba, Oracle’s standard sysdba user

l system, Oracle’s standard system user

l C##TESTER, as a common user for container (CDB) and the PDBs it contains

l CDB<n>PDB<k>TESTER, as a local user for a PDB<k> within container CDB<n>.

And where <n> and <k> are distinguishing digits.

Multitenant databases identifiers will be:

l CDB<n>, to connect to the CDB<n>$ROOT for a particular container CDB<n>,

l CDB<n>-PDB<k>, to connect to PDB<k> within CDB<n>,

For example:

CONNECT sysdba@CDB<n>

CONNECT C##TESTER@CDB<n>

CONNECT C##TESTER@CDB<n>PDB<k>

CONNECT CDB<n>PDB<k>TESTER@CDB<n>PDB<k>

When you are using a multitenant database, the connection implies that you must alter a session if youare not already connected to the required container. For example:

CONNECT C##TESTER@CDB<n> implies that, if you are not already connected to CDB<n>, then alter thesession:

ALTER SESSION SET CONTAINER = CDB<n>$ROOT;

CONNECT CDB<n>PDB<k>TESTER@CDB<n>PDB<k> implies that, if you are not already connected toCDB<n>PDB<k>, then alter the session:

ALTER SESSION SET CONTAINER = CDB<n>PDB<k>;

1.3.3 Key migration and legacy keys

Encryption master keys may be migrated from an existing Oracle keystore to an nCipher HSM, or vice-versa. In this case, and as used in this document, the term ‘key migration’ means that the responsibilityfor holding the master keys is being migrated. The encryption keys themselves are not copied (orimported) between a software keystore and HSM Security World. Fresh master key(s) are created withinthe software keystore or HSM that is to become the new key protector as a result of the migration.Subsidiary keys that are being protected are re-encrypted using the fresh master key(s). Thereafter, anynew master keys are created in the current key protector you have migrated to.


1.3.4 Paths used

During rekey, the previous master keys, or legacy keys, remain in the software keystore or HSM wherethey were created. After you have performed a key migration, you can retain access to the legacy keys inthe software keystore or HSM you have migrated away from by making its passphrase the same as thecurrent key protector’s. This allows both to be open at the same time allowing access to encryption keysthey both contain. If you do not do this, you will only be able to access keys in the current key protector. Ifyou are using both a software keystore and HSM at the same time, whichever is the current key protectoris called the primary.

1.3.4 Paths used

Throughout this document, where generic paths are presented, the default path separator will be ‘/’unless otherwise given.

Many examples in this document will show both UNIX and Windows paths. However, if generic paths areused, adjust paths and separators as appropriate to your UNIX or Windows environment.


2 Overview

2 OverviewTransparent Data Encryption (TDE) is used to encrypt an entire database in a way that does not requirechanges to existing queries and applications. A database encrypted with TDE is automatically decryptedwhen the database loads it into memory from disk storage, which means that a client can query thedatabase within the server environment without having to perform any decryption operations. Thedatabase is encrypted again when saved to disk storage. When using TDE, data is not protected byencryption whilst in memory.

The encryption keys that are used to encrypt the database are typically held as part of the database, butthese keys are themselves encrypted using a master encryption key in order to protect them. Using annShield HSM allows the master encryption keys to be kept physically separate from the database it isprotecting, and also provides a hardware protected boundary from which encryption keys can neverleave in plaintext. Additionally, the encryption keys are held in a Security World folder which is alsoencrypted and is useless to anyone who does not possess the authorized means to access them. TheSecurity World folder permits easy back up or transfer to other legitimate clients that may use theauthorized mechanisms to access the encryption keys.

Other benefits of using the nShield HSM include:

l Ability to store keys from all across an enterprise in one place for easy management.

l Key Retention (rotate keys while keeping the old ones).

l FIPS and Common Criteria compliance.


3 Installation and configuration


3.1 Preparatory requirementsBefore installing the software, we recommend that you familiarize yourself with the Oracle database TDEdocumentation and setup process, and similarly with the nCipher documentation.

We also recommend you have an agreed organizational Certificate Practices Statement and a SecurityPolicy/Procedure in place covering administration of the HSM. In particular, these documents shouldinclude the following aspects of HSM administration:

l Whether the Security World must comply with FIPS 140-2 Level 3 or Common Criteria restrictions.

l If you wish to use a FIPS 140-2 Level 3 Security World, then even if you want to use moduleor softcard protection, you must still additionally create an OCS cardset for FIPSauthorization. If you are running multiple database instances on the same host, the sameFIPS authorizing OCS cards can be used for all database instances. If you wish to use OCSprotection, the same OCS cardset used for key protection can also be used for FIPSauthorization.

l The number and quorum of Administrator Cards in the Administrator Card Set (ACS), and a policyfor managing these cards.

l Which of the following nCipher encryption key protection methods you want to use:

o Module protectiono Softcard protectiono Operator Card Set (OCS) protection. If OCS cards are to be used, you need to decide the

number of Operator Cards in the OCS cardset. K/N functionality is not currently supported.This means that you must create 1/N OCS cardsets. The number of OCS cards in a cardsetmust at least match the number of HSMs that will be in your configuration, and with more tospare in case of a card loss or failure.

l We recommend that you create a policy for managing SQL scripts that allow use of credentials forthe Oracle database. These SQL scripts should only be available to authorized users.

l We recommend that you create a policy for managing the passphrases for your:

o ACSo Module protectiono Softcard protectiono OCS protection.

For information on passphrases, see About the HSM credential on page 49.

l We recommend that you create a policy for managing the physical security of your smartcards asused for ACS and OCS, and their deployment to authorized users.

As part of your preparation, we recommend that you read Security Worlds, key protection, and failurerecovery on page 34.



This guide assumes that Oracle database software, and (at least) one Oracle database, is alreadyinstalled on your system. With Oracle database software already installed, ensure that any requiredpatches have been added.

To integrate an Oracle database with a nCipher HSM, the following steps are required:

1. Environment configuration

2. Install the nCipher HSM and Security World software

3. Configure Oracle database software to use the nCipher HSM.

Details of your installation and configuration will depend on whether you:

l Are using a Unix or Windows based host

l Are (already) using a non-multitenant or multitenant database

l Wish to migrate encryption keys from an existing Oracle software keystore to a nCipher HSM, orstart directly with a nCipher HSM

l Are using an Oracle RAC cluster.

The default host server user will be taken to be oracle unless stated otherwise.

For more information on how to configure your nCipher environment, see the User Guide for your HSM.For more information on how to configure your Oracle environment, see the Oracle documentation.

For more detail or suggestions on how you may set up your system, see the following Appendixes:

l Security Worlds, key protection, and failure recovery on page 34.

l About the HSM credential on page 49.

l Latency issues on page 55.

If you are setting up a cluster, see the following Appendixes:

l Cluster configuration suggestions on page 37.

l Setting up a remote shared folder on page 46.

3.2 Basic setting up1. If you are using nShield Solo(s), physically install them in your host server using the instructions in

the accompanying HSM documentation. We recommend that you install nShield Solo(s) beforeinstalling the nCipher Security World software.

2. Install the nCipher Security World software on each client in accordance with its accompanyingdocumentation. If you are using nShield Connects with a separate RFS, the nCipher Security Worldsoftware must also be installed on the RFS.

3. Create or edit the cknfastrc file located in theNFAST_HOME directory for each client (or RACcluster node), and depending on how you want to protect the master encryption key(s), set thefollowing PKCS11 environment variables:

Including OCS or Soft card key protection, and HSM load sharing:


3.2 Basic setting up

CKNFAST_LOADSHARING=1

Including module key protection:

CKNFAST_FAKE_ACCELERATOR_LOGIN=1

For more information, study the PKCS #11 library environment variables in the User Guide for yourHSM.

4. If you are using nShield Connect(s), configure these to operate with your selected RFS and client(s)as described in your HSM documentation. Normally the client(s) will be the host server that yourOracle database is running on. For a cluster, the clients will be each node server.

5. Depending on whether your host server has a 32-bit or 64-bit architecture, make sure thefollowing directory already exists, or else create it:

UNIX:

[32 bit] $ORACLE_BASE/extapi/32/hsm[/hsm-manufacturer/library-version/]

[64 bit] $ORACLE_BASE/extapi/64/hsm[/hsm-manufacturer/library-version/]

Make ownership and permissions on the above directory as:

owner=oracle; group=oinstall; permissions=775

Windows: Use the path prefix 'C:\oracle\extapi', not%ORACLE_BASE%.

[32 bit] C:\oracle\extapi\32\hsm[\hsm-manufacturera\library-version\]

[64 bit] C:\oracle\extapi\64\hsm[\hsm-manufacturer\library-version\]

Make sure the 'oracle' user can access the above Windows folder.

The [/library-version/] extensions should preferably in the format [/number.number.number/].

Valid directory examples on 64-bit are:

UNIX:

[64 bit] /opt/oracle/extapi/64/hsm/nCipher/v12.60/

Windows:

[64 bit] C:\oracle\extapi\64\hsm\nCipher\v12.60\



6. The nCipher PKCS#11 library file for your respective operating system is located at:

UNIX:

/opt/nfast/toolkits/pkcs11/libcknfast[-32|-64].so

Windows:

C:\Program Files\nCipher\nfast\toolkits\pkcs11\cknfast[-32|-64].dll

The [-32|-64] suffix denotes a 32-bit or 64-bit library as appropriate for your operating systemarchitecture. Typically, a default will also be provided as ‘libcknfast.so’ or ‘cknfast.dll’.

Copy the nCipher PKCS #11 library as appropriate for your OS architecture to the folder that wasprepared in step 5.

l Remove (any) [-32|-64] suffix from the copied file.

l If necessary, prefix the PKCS #11 file name with 'lib'. This should only be necessary for Windowscknfast.dll. Rename as libcknfast.dll.

For example:

UNIX:

[32 bit] $ORACLE_BASE/extapi/32/hsm/nCipher/12.60/libcknfast.so

[64 bit] $ORACLE_BASE/extapi/64/hsm/nCipher/12.60/libcknfast.so

Make ownership and permissions on the libcknfast.so file as:

owner=oracle; group=oinstall; permissions=775

Windows:

[32 bit] C:\oracle\extapi\32\hsm\nCipher\12.60\libcknfast.dll

[64 bit] C:\oracle\extapi\64\hsm\nCipher\12.60\libcknfast.dll

Make sure the ‘oracle’ user can access the libcknfast.so or libcknfast.dll file.

The PKCS#11 library file is the sole interface between Oracle and your nCipher software. If not installedcorrectly, Oracle and the nCipher software will not be able to cooperate.

7. (UNIX only): Add the oracle user to group ‘nfast’. You can verify this addition by looking at the entryfor the nfast group in /etc/group.

8. Create or load the Security World using a client, or nShield Connect (if being used). If you are usingRA for the ACS cards, you must do so through a registered client. If NOT using a cluster, ensure theSecurity World data is copied to the NFAST_KMDATA/local folder for all clients and the RFS, and isloaded onto each nShield Connect used in the configuration.

9. Check the Security World on your various components as follows:


3.3 Installing in an Oracle RAC configuration

Client:

Use the nCipher ‘nfkminfo’ utility to check the Security World and configuration on each client. In eachcase, the Security World must be shown as ‘Initialized’ and ‘Usable’.

RFS:

Use the nCipher ‘nfkminfo’ utility to check the Security World and configuration. The Security World mustbe shown as ‘Initialized’.

nShield Connect:

l Front panel: MENU = Security World mgmt. = Display World Info. The Security World must beshown as ‘Initialized’ and ‘Usable’.

l If you are using Security World software v12, on the client run the nCipher utility nethsmadmin:

>>nethsmadmin -c -m<n>

Where <n> is the module number.

The Security World must be shown as ‘Initialized’ and ‘Usable’. For further details, see theUser Guide for your HSM.

10. If your Security World does not already contain the required protection method, then proceed asfollows:

l If you wish to use module protection, no action is required (yet).

l If you wish to use softcard protection, create the required number of softcard(s), eachwith its own passphrase.

l If you wish to use a 1/N OCS cardset protection, create the required number of cardset(s) now, using exact same passphrase for each card within the same cardset.

See About the HSM credential on page 49.

11. If you are using module or softcard protection in a FIPS 140-2 Level 3 environment, then you alsoneed an OCS cardset (1/N) to provide FIPS authorization. If a suitable OCS cardset is not alreadyavailable in the Security World, then create an OCS cardset for this purpose.

3.3 Installing in an Oracle RAC configurationThe nCipher Security World software can function as part of an Oracle RAC database cluster. Thefollowing examples assume a two-node cluster that uses a shared disk, and with at least one Oracledatabase already installed. If you are using a cluster with more than two nodes, then for each additionalnode, repeat the actions as shown for Node 2 in terms of configuring your system.

Setting up for an Oracle RAC cluster is similar to that shown in the section Basic setting up on page 13, butthere are important differences in how you reference your Security World data, or locate your Oracle netconfiguration files.

Depending on which of the following parameters you are using, they should be identical on each node:



l sqlnet.ora file

l WALLET_ROOT and TDE_CONFIGURATION parameters

In the cknfastrc file for each RAC cluster node, you may consider including the following environmentvariable. But first, see Making a hardserver instance recognize new master keys on page 57 tounderstand the full consequences:

CKNFAST_ASSUME_SINGLE_PROCESS=0

All cluster configurations shown in this guide use a common shared folder to store the Security Worldkeys, see Cluster configuration suggestions on page 37. Alternatively, you may use local copies of theSecurity World on each node. But if you wish to do this, see Latency issues on page 55 to understand thefull consequences.

For suggested options on how to arrange your cluster to work with the nShield HSM, see Clusterconfiguration suggestions on page 37. Example configurations are shown for use with nShield Solos andnShield Connects. User access to the cluster will typically be through a virtual server that will have its ownname and IP address.

Oracle literature states that closing and opening the HSM on one node should do thesame for all other nodes within the cluster.

Test your chosen configuration in a safe environment before committing to a productionenvironment.

If you require assistance for different clustering arrangements, contact nCipher Support, seehttps://www.ncipher.com/services/support/contact-support.

If failure occurs on an active node, then database functionality will continue on the remaining node.Interrupted transactions may not necessarily be resumed automatically, depending on the type oftransaction that was interrupted, and how the Oracle database has been configured. See the Oracledocumentation for more information on automatic recovery of transactions. However, nCipher encryptionfacilities should remain available on the remaining node. If the failed node then recovers, nCipherencryption facilities should be automatically restored with it if you have followed the automatic recoveryconfiguration advice given in Security Worlds, key protection, and failure recovery on page 34.



4 Configuring and Using nCipher Encryption Facilities

4 Configuring and Using nCipher EncryptionFacilities

4.1 Configuring Oracle database software to use the nCipherHSMBefore proceeding, it is assumed that:

l You have followed the setting up and configuration instructions in Installation and configuration onpage 12. Therefore:

l The Oracle database software is installed with at least one database instance.

l The nCipher Security World software and HSM are installed and configured.

l Your protection method has been prepared.

l The target database is open, or if you are using a multitenant database, the target container (CDB)and all PDBs are open.

You can use the following instructions to configure your Oracle database software to function using thenCipher HSM and Security World software, in one of the following scenarios:

l Migration from keystore to HSM - One or more database instances are already using TDEencryption, each instance with its own software keystore, and you wish to continue using TDEencryption after migrating the TDE master keys from at least one keystore to the nCipher HSM.

l Create keys directly in HSM - One or more database instances are not using TDE encryption,and you wish to start using TDE encryption for at least one database, using the nCipher HSM.

Before attempting key migration, see Key migration and legacy keys on page 9. Oracle 11.1g or earlierversions might not support migration of some key types from a software wallet to a HSM. See thedocumentation for your Oracle version before attempting key migration.

The SQL commands that will be used later in this document might:

l Require more than one user with suitable database privileges to make the specific databaseconnections, and run the SQL commands in the sequences as shown. Respect the connectionsshown in order to satisfactorily run SQL on your target. See Database connections on page 8. Yoursystem administrator should have sufficient knowledge to create users and associated privilegesaccording to your organization’s security policies.

l Need to be run as a certain user. If you are instructed in this guide to make a connection as aparticular user, continue with that connection until instructed otherwise.

l Use <credential> to denote your chosen protection method. When a protection method has beeninvoked, you must continue with the same protection method unless you decide to alter it asdescribed in About the HSM credential on page 49

Oracle documentation uses the <credential-name>|<credential-passphrase> order, but we foundthat the order <credential-passphrase>|<credential-name> works.



Whenever you have completed migrating or creating encryption keys in a HSM, it isrecommended to back up your Security World data, see the User Guide for your HSM.

In SQL, the credential used to open a keystore must match the credential used to create anencryption key.

Make sure you use instructions are appropriate to whether you are using a non-multitenant databaseand software wallet, or multitenant database and software keystore.

4.2 Opening and closing a keystore or HSMOracle has a control system that gates access to a software keystore or HSM. If a keystore or HSM isopen, then you can access its contents. If a keystore or HSM is closed, then you cannot access itscontents.

You can open or close a software keystore or HSM with the following SQL statements.

l Non-multitenant only:

(Assumes database is open)

CONNECT TESTER@DB, or

CONNECT sysdba@DB

--To open wallet

ALTER SYSTEM SET [ENCRYPTION] WALLET OPEN IDENTIFIED BY "<credential>";

--To close wallet, pre-11.2.0.1.0

ALTER SYSTEM SET [ENCRYPTION] WALLET CLOSE;

--To close wallet, 11.2.0.1.0 onward

ALTER SYSTEM SET [ENCRYPTION] WALLET CLOSE IDENTIFIED BY "<credential>";

Where [ENCRYPTION] clause is optional

l Multitenant only:

(Assumes respective CDB and PDB databases are open)

-- To open keystore for the container (CDB) only.


ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<credential>";

-- To open keystore for the container (CDB) and all PDBs it holds.


ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<credential>"

CONTAINER=ALL;

-- To open keystore for a single PDB. You must use same credential as used by the containing CDB.

CONNECT PDB<k>TESTER@CDB<n>PDB<k>



4.3 Migrating from software wallet to HSM (non-multitenant)

--To close keystore

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE;

The first time you open a keystore or HSM using a credential for a particular database instance, itactivates the credential you are referencing. You should then be able to create master encryption keys,or use (any) existing master encryption keys, that are protected by that credential. You cannot have morethan one active credential at the same time for the same instance. You must close the keystore or HSM todeactivate the credential.

You can simultaneously use different credentials for different database instances on the same hostserver. For a container database only its CDB is a real instance. All PDBs within the same CDB must usethe same active credential.

In a RAC cluster, corresponding instances on different nodes must use the same active credential.

See About the HSM credential on page 49 if you want to change a credential.

4.3 Migrating from software wallet to HSM (non-multitenant)The following procedure applies in the case where the target database is non-multitenant, and you arealready using a software wallet with TDE encryption. If your target database is multitenant, see Migratingfrom software keystore to HSM (multitenant) on page 21.

We strongly recommend you back up your software wallet as an independent operation beforeattempting migration to the HSM. Keep the backup folder in a safe place separated from the associateddatabase files. Only users with authorization should be able to access the backup folder.

Repeat the following procedure for each database software wallet from which you wish to migrate. Eachindependent database instance can use its own nCipher key protection method or credential if desired.(In a RAC cluster, corresponding instances on different nodes must always use the same credential).Once a nCipher key protection method has been activated for a particular database instance, then youmust continue to use that same credential for any further keys you wish to protect for that instance,unless you change the credential as described in About the HSM credential on page 49.

4.3.1 Using the sqlnet.ora file

In the sqlnet.ora file, if you have previously been using a software wallet, then METHOD should be FILE.

1. Change the METHOD from FILE to HSM, by providing the following lines. If you are using a RACcluster, make sure your sqlnet.ora file is identical on each node, for example:

ENCRYPTION_WALLET_LOCATION=

(SOURCE=

(METHOD=HSM)

(METHOD_DATA=

(DIRECTORY=<path-to-wallet-folder>/wallet-folder)))



2. After altering the sqlnet.ora file, bounce the database for changes to take effect.


CONNECT sysdba@DB

3. Select the protection method (credential) you require below, and run the SQL.

--This will activate the credential

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY <credential> MIGRATE USING

"<wallet-passphrase>";

Important: Use the nCipher rocs utility to check that your encryption keys have been storedunder the expected protection method before proceeding.

4.3.2 Using the WALLET_ROOT and TDE_CONFIGURATION parameters

It is assumed theWALLET_ROOT parameter has already been set for Oracle keystore use.

1. Prepare for key migration by running the following SQL script:

CONNECT sysdba@DB

ALTER SYSTEM SET TDE_CONFIGURATION = "KEYSTORE_CONFIGURATION=HSM|FILE" SCOPE=BOTH

SID='*';

2. Migrate from the keystore to HSM:

CONNECT sysdba@DB

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY <credential> MIGRATE USING

<keystore-passphrase> WITH BACKUP;


4.4 Migrating from software keystore to HSM (multitenant)

Important: Migration from a multitenant software keystore to a HSM may not function correctlydue to Oracle bug 17409174. If you find the following procedure does not work, contact Oraclesupport for an Oracle patch to fix this bug as appropriate to your system.

The following procedure applies in the case where the target database is multitenant, and you arealready using a software wallet with TDE encryption. If your target database is non-multitenant, seeMigrating from software wallet to HSM (non-multitenant) on page 20.



Repeat the following procedure for each software keystore from which you wish to migrate. Eachcontainer database (CDB) can use its own nCipher key protection method (credential) if desired.However, once a nCipher key protection method has been activated for a particular database instance(CDB), then you must continue to use that same credential for any further keys you wish to protect for thatinstance, unless you change the credential as described in About the HSM credential on page 49.

You must back up your software keystore before attempting key migration to the HSM.

CONNECT sysdba@CDB<n>

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING

'<PreMigrationBackupString>' IDENTIFIED BY "<keystorepassphrase>";


1. Change your keystore passphrase to be the same as your HSM credential. Important: Select thesame credential for the protection method you will later use with the HSM.

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD

IDENTIFIED BY <keystore-passphrase> SET "<credential>" WITH BACKUP;

2. Check that the new passphrase works by closing and then opening the keystore using the newpassphrase:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<credential>"

CONTAINER = ALL;

--Check keystore is closed;

SELECT * FROM v$encryption_wallet;



CONTAINER = ALL;

--Check keystore is open

SELECT * FROM v$encryption_wallet;

3. Make your keystore into an auto-login keystore. In this case it means that you will be able to openthe keystore with the same commands as for opening the HSM. It does not mean the keystore willautomatically open after a database restart. You may need the keystore to remain open, even afteryou have migrated keys to the HSM, in order to access legacy keys:

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE

FROM KEYSTORE '<path-to-keystore-folder>/<keystore-folder>'

IDENTIFIED BY "<credential>";

4. In the sqlnet.ora file, if you have previously been using a software keystore, then METHOD shouldbe FILE. For key migration to a HSM, change the METHOD from FILE to HSM, by providing the



following lines:

ENCRYPTION_WALLET_LOCATION=

(SOURCE=

(METHOD=HSM)

(METHOD_DATA=

(DIRECTORY= <path-to-keystore-folder>/keystore-folder))))


6. Select the credential for the protection method you require with the HSM, which should be thesame as the one you previously altered for the keystore passphrase.


ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "<credential>"

MIGRATE USING <credential> WITH BACKUP;



1. Prepare for key migration by running the following SQL script:

CONNECT sysdba@CDB1ROOT

ALTER SYSTEM SET TDE_CONFIGURATION = "KEYSTORE_CONFIGURATION=HSM|FILE" SCOPE=BOTH

SID='*';

2. Create an auto-login keystore where <credential> is the HSM credential you want to use:


ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY <keystore-passphrase>

CONTAINER = ALL;

ADMINISTER KEY MANAGEMENT ADD SECRET "<credential>" FOR CLIENT 'HSM_PASSWORD' IDENTIFIED

BY <keystore-passphrase> WITH BACKUP;

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE <path-to-keystore-

folder>/<keystore-folder>/tde' IDENTIFIED BY KeystorePassword1;

3. Migrate from the keystore to HSM:


4.5 Create master keys directly in a HSM for non-multitenant database


ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "<credential>"

MIGRATE USING <keystore-passphrase> WITH BACKUP;


4.5 Create master keys directly in a HSM for non-multitenantdatabaseThe following procedure applies in the case where the target database is non-multitenant, and there is nopre-existing software wallet. If your target database is multitenant, see Create master keys directly in aHSM for multitenant database on page 25.

Repeat the following procedure for each database in which you wish to create keys. Each database canuse its own nCipher key protection method (credential) if desired. However, once a nCipher keyprotection method has been activated for a particular database instance, then you must continue to usethat same credential for any further keys you wish to protect for that instance, unless you change thecredential as described in About the HSM credential on page 49.


1. In the sqlnet.ora file, make sure the METHOD is HSM, by providing the following lines. We suggestyou keep this as a single line. For example:

ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = HSM))


3. Select the protection method (credential) you require below, and run the SQL.


CONNECT sysdba@DB

--This will activate the credential too

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<credential>";





1. Set up theWALLET_ROOT and TDE_CONFIGURATION parameters as follows. You must set uptheWALLET_ROOT parameter even if you do not use a keystore.

CONNECT sysdba@DB

ALTER SYSTEM SETWALLET_ROOT = '<path-to-keystore>' scope=SPFILE;

2. bounce the database after setting up theWALLET_ROOT parameter.

CONNECT sysdba@DB

ALTER SYSTEM SET TDE_CONFIGURATION = "KEYSTORE_CONFIGURATION=HSM" SCOPE=BOTH SID='*';

3. bounce the database after setting up the TDE_CONFIGURATION parameter.

4.5.3 Create the encryption keys

Select the protection method (credential) that you require below, and run the SQL.

CONNECT TESTER@DB, orCONNECT sysdba@DBALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<credential>";


After you created the master encryption keys in the HSM as above, proceed to encrypt your database byusing tablespace encryption, column encryption, or both, as usual.

4.6 Create master keys directly in a HSM for multitenant data-baseThe following procedure applies in the case where the target database is multitenant, and there is no pre-existing software keystore. If your target database is non-multitenant, see Create master keys directly ina HSM for non-multitenant database on page 24.

Repeat the following procedure for each database in which you wish to create keys. Each databaseinstance can use its own nCipher key protection method (credential) if desired. However, once a nCipherkey protection method has been activated for a particular database instance (CDB), then you mustcontinue to use that same credential for any further keys you wish to protect for that instance, unless youchange the credential as described in About the HSM credential on page 49.

You must create the container (CDB) master key first. After the CDB master key has been created youhave a choice of creating master keys for all the PDBs it contains in one operation, or else for each PDBindividually.



The PDB(s) must use the same protection credential as the CDB.


1. In the sqlnet.ora file, make sure the METHOD is HSM, by providing the following lines (We suggestyou keep this as a single line), for example:

ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = HSM))



1. Set up theWALLET_ROOT and TDE_CONFIGURATION parameters as follows. You must set uptheWALLET_ROOT parameter even if you do not use a keystore.


ALTER SYSTEM SETWALLET_ROOT = '<path-to-keystore>' scope=SPFILE;

2. bounce the database after setting up theWALLET_ROOT parameter.

3. Run the following command:

ALTER SYSTEM SET TDE_CONFIGURATION = "KEYSTORE_CONFIGURATION=HSM" SCOPE=BOTH SID='*';

4. bounce the database after setting up the TDE_CONFIGURATION parameter.

4.6.3 Create the CDB and then all PDB master keys in one operation

This operation appears not to work correctly using module protection. Registered as Oracle Bug25489581. For module protection, we suggest you try the section Create the CDB master key and asingle PDB master key on page 27.

1. Select the protection method you require below, and run the SQL.





CONTAINER=ALL;

2. Activate master keys for the CDB and all the PDBs in one operation

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<credential>" WITH BACKUP

CONTAINER=ALL;





4.6.4 Create the CDB master key and a single PDB master key

4.6.4.1 Create the CDB master key:

1. Select the protection method you require below, and run the SQL.


--This will activate the credential if it isn’t already


ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<credential>" WITH BACKUP;

2. Once you have created the CDB master key, you can repeat the following commands for creatinga single PDB master key, for any PDB you select.

4.6.4.2 Create a single PDB master key:

You must use the same protection method (credential) as the containing CDB. Run the SQL.

CONNECT PDB<k>TESTER@CDB<n>PDB<k>

--If the PDB is already open, you don’t need to do this.

ALTER PLUGGABLE DATABASE <CDB<n>PDB<k>> OPEN READ WRITE;

--If the keystore is already open, you don’t need to do this.


--Make the master key for the PDB you should be currently connected to.




4.7 Rekeying or key rotationAfter you have established your HSM as the primary protector for your master encryption keys, forsecurity reasons you may wish to periodically replace the keys, or rekey. For your particular system, youcan do this by following the instructions below.


4.7.1 Rekey when sharing keys between clients

The following subsections show how to perform a rekey in Oracle non-multitenant, multitenant and RACcluster environments.

After rekey, the new encryption keys should be immediately available and usable by the client thatinstigated the rekey.

4.7.1 Rekey when sharing keys between clients

If the encryption keys are being shared or distributed between clients, then either a common sharedSecurity World folder, or local client copies of the Security World folder, will be used. This also applies toan RAC cluster. In this case, you must factor in:

l Encryption key distribution and synchronization with the associated encrypted data in the Oracledatabase

l Recognition of new encryption keys by the nCipher hardserver instance on each client.

For the new keys to be recognized by a client hardserver instance (that did not instigate the rekey), youmust first be sure that the new keys are available in the Security World folder it is using. If the new keysare available, then you can make the client hardserver instance recognize and use the new keys byeither of the following options:

l Include in the client cknfastrc file, the environment variable:


Or:

l Reconnect all users/applications on the client that are using the database encryption facilities.

The above actions will cause the available keys to be scanned by the client’s hardserver instance, andany new keys will then be recognized and made usable. See Latency issues on page 55 to understandthe full consequences of these options.

It is the job of your system administration to ensure that distribution and recognition of shared (new)encryption keys is performed smoothly. In the (unlikely) event that synchronization problems cannot beresolved with the system in continual operation, it may be necessary to temporarily halt encrypteddatabase operations on all clients other than the one that instigates the rekey. After rekey has beenperformed, with correct keys available and recognized by all clients, then the system can be restored tonormal operations.

Test your rekey arrangements in a safe environment before committing to a productionenvironment.

Transactions restricted to unencrypted data will not be affected by rekey operations.



Before rekeying, you should inspect the contents of your Security World local folder, and notethe date/time that you perform a rekey. After rekeying, you should verify that new key fileshave been created in your Security World ‘local’ folder by inspection, and check the date/timestamp of new key files in the folder match the date/time you performed the rekey.

4.7.2 Rekey for a non-multitenant database

The following instructions begin by assuming the HSM (wallet) is already open.

CONNECT TESTER@DB, or CONNECT sysdba@DB --Assumes HSM is already open

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<credential>";

4.7.3 Rekey for a multitenant database; CDB and all the PDBs in one operation

The following instructions begin by assuming the required CDB has started, and required PDBs and HSM(keystore) to be already open.

CONNECT TESTER@CDB<n> --Assumes CDB has started all required PDBs and HSM already open

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<credential>" WITH BACKUP CONTAINER=ALL;

4.7.4 Rekey for a multitenant database; CDB only

The following instructions begin by assuming the required CDB has started and HSM (keystore) to bealready open.

CONNECT TESTER@CDB<n> --Assumes CDB has started and HSM already open


4.7.5 Rekey for a multitenant database; single PDB only

The following instructions begin by assuming the required CDB has started, the required PDB and HSM(keystore) to be already open.

CONNECT PDB<k>TESTER@CDB<n>PDB<k> --Make the master key for the PDB you should be currently

connected to


4.7.6 Rekey in a RAC cluster

See Rekey when sharing keys between clients on page 28 before attempting rekey in an RAC clusterenvironment.


4.7.6 Rekey in a RAC cluster

Select one node within the cluster on which to perform a rekey. Usually this is the active node. On theselected node, depending on whether your cluster database is non-multitenant or multitenant, theninvoke the required rekey operation as described in the sections above.

If you are rekeying within the context of a Security World shared in common across all cluster nodes, thenrekeying on one node of the cluster should implicitly make the new key(s) available to all other nodes.See Cluster configuration suggestions on page 37.

If you are rekeying where each node has its own local copy of the Security World folder, make sure thenew keys are available in every node’s Security World folder before proceeding.

If rekey is successful, the new keys will be immediately usable by the node that instigated the rekey.However, for all other nodes in the cluster, for the new keys to be recognized by a node hardserverinstance, then for each node you must either:

l Include in the client cknfastrc file, the environment variable:


Or:

l Reconnect all users/applications on the client that are using the database encryption facilities.

The above actions will cause the available keys to be scanned by the node’s hardserver instance, andany new keys will then be recognized and made usable. However, see Latency issues on page 55 tounderstand the full consequences of these options

If you are using the configuration as shown in Common Security World on shared disk on page 42, thenadditionally you must update the encryption keys as stored in the RFS by using the following commandon (any) client node:

>> rfs-sync –commit


5 Troubleshooting

5 TroubleshootingOracle error messages may sometimes show error symptoms rather than the root cause. If you see anerror you have not met before, we suggest you search for further information online before attempting toresolve the error. If you remain unable to resolve the error, contact Oracle support.

If you are using a UNIX based host server, we suggest that if you edit an Oracle configuration file thenuse a simple text editor running on the host. Do not cut and paste the file contents from another file usinga formatting editor, as it may insert hidden characters that are difficult to detect and which can stop thefile from working. We also suggest you avoid copying files onto a UNIX host via a Windows intermediary(this includes library files).

If you are troubleshooting using a multi-node cluster, make sure you are investigating the node on whichthe problem is occurring.

The following table provides troubleshooting guidelines.

Problem Suggested solution

An SQL command is run, andthere is no output, or anunexpected output or erroroccurs.

Try reconnecting to the database.

If that doesn’t work, try bouncing the database.

After a change to a con-figuration file, no resultantchange in the database beha-vior is observed.


If that doesn’t work, try bouncing the database.

ORA-28367: wallet does notexist

Check that you have correctly installed and configured the nCipherpkcs11 library. See section Basic setting up on page 13

Check that your sqlnet.ora file contains the correct location, issyntactically correct, and has the required permissions.


Try bouncing the database.

Try restarting the nCipher hardserver.

ORA-28367: cannot find

PKCS11 libraryIn path variables, do not confuse \ separators for Windows, and /separators for UNIX. Ensure that you have correct permissions to usethe opt/oracle/extapi/… directory.

Check that you are using a library for the correct local architecture(32/64).

Check that you are using the appropriate Java version (32/64).

Please refer to advice given above about editing Oracle files, or copying


5 Troubleshooting


them.


Recopy the libcknfast.so library file to /opt/oracle/extapi/.

In theORACLE_BASE/extapi folder, create a link named libcknfast.so tothe actualNFAST_HOME/toolkits/pkcs11/libcknfast.so file.

ORA-28353: failed to openwallet

Check that you have set up your cknfastrc file with the correct contents.Ensure that the HSM wallet pass phrase is correct. Ensure that ifOCS/softcard key protection is used, the name and passphrase are cor-rect and are separated by a | or :. If you have migrated from an Oraclewallet to a HSM wallet, you must update the passphrase.

ORA-28407: Hardware

Security Module failed with

PKCS#11 error CKR_

FUNCTION_FAILED (%d)

This may be caused by Oracle bug 23528412: Please contact Oraclesupport in order to obtain a patch for this bug.

Ensure that if a FIPS 140-2 Level 3 Security World is in use, an OCS cardis inserted in the HSM slot.

Check that you are using the correct passphrase/credential to accessthe HSM.

If you are using an nShield Connect, use its front panel to check theSecurity World is loaded on to the HSM itself and is both Initialized andUsable.

Try restarting the nCipher hardserver.

When attempting to migrateencryption keys from asoftware keystore to a HSM,or vice-versa, the keys do notmigrate correctly.

This may be caused by Oracle bug 17409174.

Please contact Oracle support in order to obtain a patch for this bug.

When you are using per-sistent OCS cards, the per-sistent authorization is lost.

This may be caused by Oracle bug 23528412: Please contact Oraclesupport in order to obtain a patch for this bug.

Ensure that, as the required OS user, you can access both the nCipherand Oracle functionality. If necessary, adjust user group membership topermit this, but check your security policy first.

ORA-00600: internal errorcode, arguments:[kzthsmgmk: C_GenerateKey], [6], [],[], [], [], [],[]

Ensure that you have added user oracle to group nfast. In some cases,you may have to re-login with the oracle user for this to take effect.Ensure that if a FIPS 140-2 Level 3 Security World is in use, an OCS cardis inserted in the HSM slot.

ORA-00600: internal errorcode, arguments:

Sometimes occurs using encrypted tablespaces. This may be causedby Oracle bug 21080143: Please contact Oracle support in order to


5 Troubleshooting


[ksqgel:null_parent], [], [],[], [],[], [], []

obtain a patch for this bug.

ORA-28374: Typed masterkey not found in wallet.

Oracle software thinks there is a mismatch between encrypted object(s)and available master key(s). There is more than one possible cause forthis and it is usually quite difficult to resolve. Contact Oracle support, orsearch for solution online.

If all else fails, try and restore your system from backups.

ORA-12162: TNS: net servicename is incorrectly specified

Check that you have correctly set the value for ORACLE_SID in your localenvironment.


Appendix A Security Worlds, key protection, and failure recovery

Appendix A Security Worlds, key protection, andfailure recoveryThis section highlights some considerations when choosing Security World and key protection options foruse with the nCipher Security World. It focuses on recovery of Security World authorization where asystem has temporarily failed (for instance after a power outage) and is then returned to operation. Thisdoes not apply to other failure recovery functions. These considerations are applicable to SecurityWorlds, key protection and failure recovery for both standalone systems and database clusters. For afuller explanation of Security Worlds and key protection please refer to the User Guide for your HSM.

In the event of a temporary failure of the nCipher Security World, there may be a consequent loss of:

l Credential authorization

l Authorization if you are using a FIPS 140-2 Level 3 Security World

A credential authorization can be granted using either a softcard or an OCS card, with passphrase. In thecase of an OCS, a card must be always available in a valid HSM card reader in order to grant re-authorization after a failure, and permit automatic recovery.

Where FIPS authorization is required, this can be granted either by using an OCS card specifically for thispurpose, or through an OCS card that is also used for credential authorization. A card from the OCS mustbe always available in a valid HSM card reader in order to grant reauthorization after a failure, and permitautomatic recovery.

If you are using OCS cards through a RA secure channel, then if the secure channel is lost it must be re-established before recovery using the OCS cards can begin. There is no automatic mechanism to re-establish the secure channel, which would have to be re-established manually, or through some (userdefined) script. For this reason, we do NOT recommend that RA is used for systems requiring automaticrecovery.

Oracle autologin facilities need to be set up to implement automatic recovery in the event of a temporaryfailure.

Never use ACS cards for FIPS authorization, because they do not support automatic recovery.

Softcards or OCS must be members of the same Security World.

The following table describes the authorization recovery behavior of the nCipher Security World after atemporary outage.



SecurityWorld type

Protection/Credential

Stand-alone system Database cluster

FIPS level 2 Module Recovers automatically Recovers automatically

Softcard Recovers automatically Recovers automatically

OCS Use OCS for credentialauthorization:

l Use 1/N quorum. Samepassphrase for all cards

l Leave an OCS card in HSMslot.

Recovers automatically

Use OCS for credential authorization:

l Use 1/N quorum. Samepassphrase for all cards

l Leave an OCS card in slot ofevery HSM in cluster.


FIPS level 3 Module Use OCS for FIPS authorization(only):



Use OCS for FIPS authorization (only):



Softcard Use OCS for FIPS authorization(only):



Use OCS for FIPS authorization (only):



OCS Use OCS for both credential andFIPS authorization:

l Use 1/N quorum. Samepassphrase for all cards.


Recovers automatically.

Use OCS for both credential and FIPSauthorization:

l Use 1/N quorum. Samepassphrase for all cards.


Recovers automatically.

Recovery behavior

If you are using an OCS to facilitate automatic recovery of the nCipher Security World:

l If you are using the OCS for credential authorization, all must be members of the same card set forthe same credential, and the same passphrase must be assigned to every card in the set.

l If you are using the OCS for FIPS authorization purposes only, the quorum automatically defaultsto 1/N, and (any) passphrase is ignored.



Authorization acquired through a persistent operator card does not automatically reinstateitself after loss due to a temporary failure.


Appendix B Cluster configuration suggestions


B.1 Oracle RAC configuration using nShield SolosA two-node Oracle RAC example that is configured to use nShield Solo based HSMs is shown in FigureB.1.

The shared disk holds:

l The Oracle database information at <shared-disk-folder>/oradata/(database)

l The nCipher Security World data at <shared-disk-folder>/local

Figure B.1 Oracle RAC configuration using nShield Solos

To implement this configuration:

1. On Node 1, complete the installation instructions in Basic setting up on page 13 (all steps, includingSecurity World creation).



2. On Node 2, complete steps 1 to 7 of the installation instructions in Basic setting up on page 13. Donot create a Security World on Node 2.

3. For the database cluster to function correctly between nodes, the Security World data must bestored in the shared network drive for the cluster. If the shared network drive contains the <shared-

disk- folder> then create the following directory path on that drive, through the active server:

UNIX:

<shared-disk-folder>/local

Windows:

<shared-disk-folder>\local

Make sure the 'oracle' user can access the folder.

4. On Node 1 and Node 2, do the following:

a. Create the environment variableNFAST_KMLOCAL and set its value to that of the shareddirectory path, for example:

NFAST_KMLOCAL=<shared-disk-folder>/local

b. Make Node 1 active in the cluster. From Node 1 the contents of the directoryNFAST_KMDATA/local must be copied to the shared directory <shared-disk-folder>/local.

c. Make Node 2 active in the cluster. Load the Security World onto the Node 2 HSM. See theUser Guide for your HSM if you require help.

d. Use the nCipher nfkminfo utility to check the Security World and configuration on each client.In each case, the Security World must be shown as Initialized andUsable.

If you have not already prepared the protection method you will use, see steps 10 to 11 of the Basic settingup on page 13.

Please note that in the configuration shown Figure B1, the shared disk is a single point of failure for boththe Oracle database and nCipher Security World data. It is essential that both are backed up on afrequent and regular schedule.

B.2 Oracle RAC configuration using nShield ConnectsTwo alternative configurations for use with nShield Connects are shown in Figure B.2 and Figure B.3. Inboth cases a separate server is required to act as host for the RFS.


B.3 Common Security World on RFS

B.3 Common Security World on RFSThe RFS shown in Figure B.2 is configured to hold the Security World data as a shared folder that can beremotely accessed, and is held in common, by Node 1 and Node 2 of the cluster. The Oracle database isheld separately on the cluster shared disk. Since the Security World data is held in common on the RFSbetween both nodes, then the data on the RFS is always automatically up to date no matter which node isin use, and there are no issues in keeping the RFS data synchronized with any other copies.

Advantages:

l Update of Security World data on the RFS is implicit and simple (as there is only one store)

l Single store implies no data distribution and synchronization issues as would be the case withmultiple copies of the store

l Keeps update time delays short, thereby minimizing any problems in synchronizing keys with data

l The Security World and database are held on physically separate disks. This is more secure than ifboth were held on the same disk.

Disadvantages:

l The RFS is a single point of failure for the Security World data. To avoid potential loss of encryptionkeys, the Security World data on the RFS must be backed up either every time the data changes,or else on some frequent and regular basis.



Figure B.2 Oracle RAC configuration using Common Security World on RFS

B.3.1 Implementing the Common Security World on RFS configuration

To implement the configuration shown in Figure B.2:

1. Install Security World software on the RFS.

The RFS can be either UNIX/Linux or Windows based. See the User Guide for your HSMfor installation help.

2. On the RFS, make the directory NFAST_KMDATA/local a shared folder that is visible on the network.

a. For a UNIX/Linux based RFS, see Where the remote server is UNIX/Linux based on page 46

b. For a Windows based RFS, see Where the remote server is Windows based on page 46


B.3.1 Implementing the Common Security World on RFS configuration

3. Grant permissions on the RFS shared network folder for all users of the Oracle database needingto use the nCipher Security World encryption. Note: As well as permissions to use the sharedfolder, the users may also require remote access permissions to the RFS. Check yourorganization’s security policies before making changes to permissions.

4. On Node 1 and Node 2, complete steps 1 to 7 of the installation instructions in Basic setting up onpage 13. Do not proceed to create or load a Security World.

5. On Node 1 and Node 2, configure each node to be able to reference the RFS shared network folderas described in Where the local client is UNIX/Linux based on page 47.

6. On Node 1 and Node 2, set the environment variable NFAST_KMLOCAL to reference the sharednetwork folder on the RFS. For example:

NFAST_KMLOCAL=<RFS-server-name>/local

You may wish to set this in a configuration file for more permanent usage.

Check that you can see the remote folder from Node 1 and Node 2 by running:

UNIX:

>>ls –l $NFAST_KMLOCAL

Windows:

>>dir "%NFAST_KMLOCAL%"

7. Create or load the desired Security World using a client (node) or nShield Connect (if you are usingRA for the ACS cards, you must do so through a registered client). Ensure the Security World isloaded onto each nShield Connect. For details, see the User Guide for your HSM.


l Client: Use the nCipher nfkminfo utility to check the Security World and configuration oneach client. In each case, the Security World must be shown as Initialized and Usable.

l RFS: Use the nCipher nfkminfo utility to check the Security World and configuration. TheSecurity World must be shown as Initialized.

l nShield Connect:

l Front panel: MENU => Security World mgmt. => Display World InfoThe Security World must be shown as Initialized and Usable.

l If you are using Security World software v12, on the client run the utility:

nethsmadmin -c -<module number>

The Security World must be shown as Initialized and Usable.



For further details, see the User Guide for your HSM.

If you have not already prepared the protection method you will use, see steps 10 through 11 of thesection Cluster configuration suggestions on page 37.

If there is failure of the entire system (for instance a temporary power loss) then the RFS andnShield Connects should be re-powered before the failover cluster.

B.4 Common Security World on shared diskThe Security World data shown in Figure B.3 is contained in a shared folder held in common on theshared disk by Node 1 and Node 2 of the cluster. Since the Security World data is held in commonbetween both nodes, then the Security World data on the shared disk is always automatically up to dateno matter which node is in use. In this case, the RFS holds a separate copy of the Security World datawhich must be kept up to date, or synchronized with the shared disk copy by setting up RFSsynchronization facilities. The synchronization can be done manually, or on some automatic basis using asuitable shell script.

Advantages:

l Update of Security World data on the shared disk is implicit and simple (as there is only one store),

l Single store implies no data distribution and synchronization issues as would be the case withmultiple copies of the store

l Keeps update time delays short, thereby minimizing any problems in synchronizing keys with data

l The RFS holds a separate and backup copy of the Security World data which is held on a physicallydifferent machine to the shared disk copy

l The RFS backup copy of the Security World mitigates the shared disk being a single point of failurefor the Security World data

l The shared disk copy of the Security World mitigates the RFS being a single point of failure for theSecurity World data backup.

Disadvantages:

l The RFS must be synchronized with the shared disk Security World data, either every time the datachanges, or else on some frequent and regular basis, if it is to remain a reliable backup copy

l The Security World and database are held on the same disk. As both encryption keys and data areheld together on the same physical device, this is less secure than if each was held on separatedisks. A potential data thief may find it convenient that the data and associated encryption keys areheld on the same medium, even though they still face the severe problem of decrypting theSecurity World data before they can access the encrypted database.


B.4.1 Implementing the Common Security World on shared disk configuration

Figure B.3 Oracle RAC configuration using Common Security World on shared disk


To implement the configuration shown in Figure B.3:

1. Install Security World software on the RFS.

The RFS can be either UNIX/Linux or Windows based. See the User Guide for your HSMfor installation help.

2. On Node 1 and Node 2, complete steps 1 to 7 of the installation instructions in Basic setting up onpage 13. Do not proceed to create or load a Security World.



3. For the database cluster to function correctly in failover mode, the Security World data must beheld in the shared network drive for the cluster. If the shared network drive contains the <shared-disk- folder> then create the following directory path on that drive, through the active server:

<shared-disk-folder>/local

4. On Node 1 and Node 2, create the environment variableNFAST_KMLOCAL and set its value to thatof the shared directory path. For example:

NFAST_KMLOCAL=<shared-disk-folder>/local

You may wish to set this in a configuration file for more permanent usage.

Check that you can see the shared folder from Node 1 and Node 2 by running:

UNIX:


Windows:

>>dir "%NFAST_KMLOCAL%"

5. Create or load the desired Security World using a client (node) or nShield Connect (if you are usingRA for the ACS cards, you must do so through a registered client). Ensure the Security World iscopied to the RFS. Ensure the Security World is loaded onto each nShield Connect. For details, seethe User Guide for your HSM.


l Client: Use the nCipher nfkminfo utility to check the Security World and configuration oneach client. In each case, the Security World must be shown as Initialized and Usable.

l RFS: Use the nCipher nfkminfo utility to check the Security World and configuration. TheSecurity World must be shown as Initialized.

l nShield Connect:

l Front panel: MENU => Security World mgmt. => Display World InfoThe Security World must be shown as Initialized and Usable.

l If you are using Security World software v12, on the client run the utility:

nethsmadmin -c -<module number>

The Security World must be shown as Initialized and Usable.



For further details, see the User Guide for your HSM.

7. On the RFS, set up synchronization as follows. For more details about RFS synchronization, seethe User Guide for your HSM.

>>rfs-setup --gang-client --write-noauth <Node1 IP Address>

>>rfs-setup --gang-client --write-noauth <Node2 IP Address>

9. On each client, set up synchronization as follows:

>> rfs-sync --setup –no-authenticate <RFS IP Address>

The above synchronization settings should be saved in the Security World configuration files. Afteryou have set up synchronization as shown above, in order to update the Security World data in theRFS, from either client node you can use the following command. This will push new keys from theclient to RFS.

>>rfs-sync --commit

You can also pull keys from the RFS to a client by running the following command on a client:

>>rfs-sync --update

If you have not already prepared the protection method you will use, see steps 10 to 11 in Basicsetting up on page 13.

If there is failure of the entire system (for instance a temporary power loss) then the RFSand nShield Connects should be re-powered before the failover cluster.


Appendix C Setting up a remote shared folder

Appendix C Setting up a remote shared folderBefore setting up a remote shared file, please refer to your organization’s security policies to ensure youcomply with security requirements.

C.1 Where the remote server is UNIX/Linux basedThis description assumes the use of the samba service.

On the UNIX/Linux based remote server:

1. Make sure samba is installed and the samba service is enabled.

2. Make sure the folder you want to share exists, for example: /opt/nfast/kmdata/local

Where local is the folder you want to share.

3. Make a copy of the /etc/samba/smb.conf file for safe keeping.

4. Edit the file /etc/samba/smb.conf and append fields similar to the following for the local folder, forexample:

[local] path = /opt/nfast/kmdata/local valid users = oracle browsable = yes writable = yes read only = no force user

= nobody guest ok = no

Make sure there is white space either side of the = sign.

In the example above:

l path is the path to the folder to be shared

l valid users are the user names permitted to access the folder. If you require more thanone user, you can provide a comma-separated list.

6. After saving the /etc/samba/smb.conf file, restart the samba service:

>>/bin/systemctl restart smb.service

C.2 Where the remote server is Windows basedOn the Windows based remote server:

1. Make sure the folder you want to share exists, for example:

C:\ProgramData\nCipher\Key Management Data\local

Where local is the folder you want to share.


C.3 Where the local client is UNIX/Linux based

3. If you only want specific users to be able to share the folder, you may need to set up a user accountfor them if none already exists. Make sure you give the user remote access permissions.

4. In Windows Explorer, select the folder you want to share (e.g.local), right-click and select Sharewith -> Specific people.

5. Add the users you want to share the folder with.

Check your organizations security policies before doing this.

C.3 Where the local client is UNIX/Linux basedSet up the remote server before setting up the local client.

A UNIX/Linux client set up as shown below should be able to see the shared folder on either aUNIX/Linux or Windows server that is set up as shown above.

This procedure assumes the use of samba.

On the UNIX/Linux based client server:

1. Make sure samba is installed and the samba service is enabled.

2. If the remote shared folder you wish to use is on <remote-server-name> and the folder name islocal, make sure the following named folder exists on the client:

/<remote-server-name>/local

4. Edit the file /etc/samba/cifs and append fields similar to the following:

username=<user-name-on-remote-system> password=<user-passphrase-on-remote-system>

domain=<domain-of-remote-system>

For example:

username=oracle password=oracle-password domain=some-domain

7. Edit the file /etc/fstab and append fields similar to the following:

//<remote-server-name>/local /<remote-server-name>/local cifs credentials=/etc/samba/cifs 0 0

In some cases, it may be necessary to include Samba permissions directives.

9. Save the /etc/fstab file, and then restart the samba service:


Appendix C Setting up a remote shared folder

>>/bin/systemctl restart smb.service

11. Mount the local directory, for example:

>>mount /<remote-server-name>/local

13. If the shared folder set up has worked, you should be able to see the contents of the remoteshared folder, for example:

>>ls –l /<remote-server-name>/local

You can also set up the path to the remote shared directory as a local variable, for example:

export NFAST_KMLOCAL=/<remote-server-name>/local

You should then be able to see the contents of the remote shared folder by using the variable, forexample:



Appendix D About the HSM credential

Appendix D About the HSM credentialThe protection methods available with the nCipher HSM are, in order of enhanced authentication:

HSM Protection Encryption Description

Module Encryption keys are protected by a nCipher Security World protectingkey in the HSM.

Softcard Encryption keys are protected by a named softcard (software based)token key, a passphrase, and nCipher Security World protecting key inthe HSM. You can have many different softcards, but each is singularand works on its own.

OCS Encryption keys are protected by the presence of a named physicaltoken (OCS smartcard), an OCS token key, a passphrase, and nCipherSecurity World protecting key in the HSM. OCS cards are usually part ofa set of several OCS cards, or cardset, and any member of the samecardset protects the same encryption keys. You can have many dif-ferent OCS cardsets where each cardset may protect different encryp-tion keys.

The softcard and OCS protection methods must be set up within the nCipher HSM before they can beused by an Oracle database. See your HSM User Guide for details. The module protection method can beused directly without any set up (other than the normal nCipher configuration). Setting up the softcard orOCS includes creating and naming the token(s), with a passphrase (see your HSM User Guide).

Within SQL scripts as used by Oracle, we can identify the protection method using a <credential>.Choose the protection method you wish to use where <credential> becomes one of:

Protection Type Credential or <credential>

Module protection <module-passphrase>

(In this case the passphrase is an access mechanism for Oracle, and isnot used by the nShield HSM)

Softcard protection <softcard-passphrase>|<softcard-name>

OCS protection <OCScard-passphrase>|<OCScard-name>

Oracle literature gives the ordering <credential-name>|<credential-passphrase>, but wefound the ordering <credential-passphrase>|<credential-name> works.

Oracle SQL uses the separator symbol | or else : to divide the <credential-passphrase> and <credential-

name>. Hence the total Oracle SQL string for a credential comprises:

l Module protection: <passphrase>

l Softcard or OCS card protection: <credential-passphrase> + <separator> + <credential-name>.



In the nCipher Security World, we recommend the following restrictions on token names, or credential-name:

l Maximum length of 254 characters.

l ASCII 7-bit characters only, restricted to:

A-Z, a-z, 0-9, $ - _ (no white space).

In the nCipher Security World, we place the following restrictions on passphrases, or credential-passphrase:

l Maximum length of 254 characters.

l ASCII 7-bit characters only:

A-Z, a-z, 0-9, ! @ # $ % ^ & * - _ + = [ ] { } | \ : ' , . ? / ` ~ " < > ( ) ; (no white space).

However, the Oracle SQL interface imposes further restrictions on top of the nCipher restrictions for whatcan comprise the string <credential-passphrase> + <separator> + <credential-name>, as follows:

l The total string length, including separator, can be no more than 30 characters. This leaves 29characters for the <credential-passphrase> + <credential-name>

l The symbols | : " ' cannot be used within the <credential-passphrase> or <credential-name>.

From the Oracle side, if:

N is the length of the credential nameP is the length of the credential passphrase, then 2 <= (N+P) <= 29, where 1 <= N <= 28, and 1 <= P<= 28, assuming a minimum of one character for passphrase and name.Permitted symbols are:

l <credential-passphrase>A-Z, a-z, 0-9, ! @ # $ % ^ & * - _ + = [ ] { } \ , . ? / ~ < > ( ) ; (no white space)

l <credential-name>:A-Z, a-z, 0-9, $ - _ (no white space).

Use a passphrase of sufficient length to meet your current security requirements.

Oracle (wallet manager) states “Passwords must have a minimum length of eight charactersand contain alphabetic characters combined with numbers or special characters".

When you are using a softcard or OCS credential, an SQL script that uses the credential mustget the <credential-passphrase> and <credential-name> exactly correct. If there is a mistake,then the entire credential string may be misinterpreted as a <module-passphrase>. Yourencryption keys are then placed under module protection rather than the softcard or OCScard protection you intended. For this reason, after creating encryption keys or rekeying, thenimmediately use the ncipher rocs utility to check the keys you have just created are under theexpected credential or protection method.

In the examples shown in this guide, credentials may be given descriptive names to make it clear whatthey are used for, such as <keystore-credential>. In practice, replace the descriptive names with theactual credential passphrases and names you are using.


D.1 Change passphrase only

If you want to change the passphrase for softcards or OCS cards, you must change the passphrase forthe token in the nCipher Security World first, followed by updating the change to the database. Formodule protection you need only change the passphrase as seen by the database.

If you are using a FIPS 140-2 Level 3 Security World:

l To change the passphrase of a softcard, or create a new softcard, you require either authorizationusing ACS cards, or an OCS authorizing card.

l To change the passphrase of an OCS card, or create a new OCS card, you require authorizationusing ACS cards.

You can change the protection method or credential in one of the following ways:

l Continue using the same protection method and token, but change the associated passphrase.There is no token for module protection, but you can change the passphrase. In this case, after thepassphrase is altered, TDE continues working using the new passphrase, because the protectedTDE encryption keys remain the same.

l Continue using the same protection method, but change the token and passphrase. In this case,you have two options:

l If you are not transferring encryption keys from the previous token to the new token, youcan no longer continue using TDE as protected by the previous token’s keys. You will onlybe able to use TDE encryption keys shielded under the newly activated credential.

l If you are transferring encryption keys from the previous token to the new token, you cancontinue using TDE as protected by the previous token’s keys. However, you can onlytransfer keys from different softcards, or different OCS cards. You cannot transfer keysbetween softcards and OCS cards.

l Change the protection method and associated credential with passphrase. In this case, you cannottransfer encryption keys between the different protection methods. You can only use TDEencryption keys shielded under the new protection method and credential.

D.1 Change passphrase onlyTo change a passphrase only, complete the following instructions:


CONNECT TESTER@DB

ALTER DATABASE OPEN; --If not open already

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE; -- Pre-11.2.0.1.0

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY “<credential>”; -- 11.2.0.1.0 onward

l Multitenant only:




ALTER PLUGGABLE DATABASE ALL OPEN; --If not open already

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<old-credential>" CONTAINER=ALL;

At this point:

If you are using module protection, skip to the next SQL statements.

If you are using softcard protection, please refer to your HSM User Guide for instructions on how tochange the softcard passphrase using the ppmk utility.

If you are using OCS protection, please refer to your HSM User Guide for instructions on how to changethe OCS passphrase using the cardpp utility. If you are using OCS cards, all OCS cards within the same(1/N) cardset must be altered to share the exact same passphrase.

Bounce database.


CONNECT TESTER@DB


ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<new-credential>";

l Multitenant only:



ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-

credential>" CONTAINER=ALL;

D.2 Change token with associated passphrase but keep sameprotection method

This does not apply to module protection.

To change a token with passphrase for the same protection method, complete the following instructions:


CONNECT TESTER@DB





D.3 Change protection method

l Multitenant only:



ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE

IDENTIFIED BY "<old-token-credential>" CONTAINER=ALL;

At this point:

If you do not wish to transfer TDE encryption keys from the previous token to the new token, skip to thenext SQL statements. If you are using an OCS cardset (1/N), all OCS cards within the new cardset mustshare the exact same passphrase.

If you do wish to transfer TDE encryption keys from the previous token to the new token, please refer toyour HSM User Guide for instructions on how to transfer the keys using the rocs utility.

It is recommended to back up your Security World data before transferring keys betweentokens. See the User Guide for your HSM.

To transfer keys using the rocs utility, you will need your Security World ACS cards to authorize transferof keys between tokens. You can only transfer encryption keys between softcards, or else between OCScards, but not between softcards and OCS cards. If transferring keys to another OCS cardset (1/N), allOCS cards within the target cardset must share the exact same passphrase.

Bounce database.


CONNECT TESTER@DB


ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<new-token-

credential>";

l Multitenant only:



ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-token-


D.3 Change protection methodTo change the protection method, complete the following instructions:




CONNECT TESTER@DB




l Multitenant only:



ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<old-protection-credential>"

CONTAINER=ALL;

If you are using OCS cards, all OCS cards within the same (1/N) cardset must share the exact samepassphrase.

Bounce database.


CONNECT TESTER@DB


ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<new-protection-credential>";

l Multitenant only:



ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-protection-



Appendix E Latency issues

Appendix E Latency issuesIt is beyond the scope of this guide to deal with specific solutions to latency issues, and these will only bediscussed in general terms.

When you are using an Oracle database, the nCipher Security World provides and protects the masterencryption keys (wrapping keys) that are used to wrap Oracle symmetric keys that are in turn used fortablespace or table column encryption. The Oracle symmetric keys are stored as part of the databaseitself, although protected by the wrapping key.

In the context of this guide, encrypted data will be taken to include the symmetric key(s) that are stored aspart of an Oracle database, as well as the encrypted data itself. Master encryption keys will be taken tobe the (wrapping) keys stored by the nCipher Security World. Latency issues may occur when there is amismatch between the encrypted data and the (correct) master encryption keys, due to a time lag in anupdate of either.

This should only be a problem where there are multiple clients using the same database and encryptionkeys. This includes Oracle RAC clusters. In this case, when data or master encryption keys are updatedon one client, the changes must be distributed before use by the other clients. Otherwise synchronizationproblems may occur. Note that the client that instigates the changes should suffer no synchronizationproblems.

Typically, these issues are more complex to resolve for a large and geographically distributed databasesystem, rather than a small or localized system. It is the job of the system administration to ensure thatencrypted data is synchronized with the appropriate master encryption keys at any particular time.Furthermore, is not within the control of the nCipher software if encrypted data does not match (thecorrect) master encryption keys in the Security World because of a time lag in updating the database.

Where there may be a time lag in updating master encryption keys in the Security World to matchencrypted data, this may be due to the following:

l Time lag in distributing new or updated master encryption keys to a Security World, or betweendifferent copies of the same Security World, after a key rotation or rekey.

l After new or updated master keys have been successfully distributed to the Security World, then alag in making a nCipher hardserver instance recognize the new master keys.

E.1 Storage and distribution of updated master keys

E.1.1 Common storage of master encryption keys

We recommend configurations where the Security World data is held in common storage between clientsthat require use of the same master encryption keys (if possible). This is the case for the clusterconfigurations as shown in Cluster configuration suggestions on page 37, although it may also apply tonon-cluster clients that need to share the same master keys.

If common storage of the master encryption keys is being used, then there may be a short time delaybefore newly created keys are successfully copied to the common store. After this, there may be a further



short time delay before a client is able to access the keys from the common store. The time period a clientmay not be able to access the updated keys is likely to be very short, but may increase if the client isgeographically distant from the common store and communication delays accumulate. Note that if youare using a common store, the master keys are implicitly updated for the use of all clients, and there is noneed to trigger any other update mechanism.

Common key storage implies:

l Key update is implicit and simple (as there is only one store)

l Keeps time delays short, thereby minimizing any problems synchronizing keys with data

l It is essential the common store is backed up frequently, as otherwise it is the only copy of theencryption keys.

E.1.2 Local storage of master encryption keys

If each client is using its own local copy of the Security World, then after an update of the master keys isinstigated on any client, the updated keys must be distributed in a timely manner to the local SecurityWorlds of every other client. To achieve this, there must be some explicit update mechanism in order torecognize when an update is required in the first place, and then trigger the key distribution process.

Clearly, if this was done manually, it is likely to be a slow process. If it is done automatically, recognizingwhen a rekey occurs should not be difficult on the client that instigates it, and triggering the update shouldnot therefore be a problem. Even so, for a configuration that uses dispersed local copies of the SecurityWorld, mechanisms to distribute the updated keys are likely to be slower and more difficult to implementthan for the common key storage case. This makes the timely synchronization of the master keys withthe data more problematic.

nCipher provide the utilities rfs-setup/rfs-sync (gang-client) that can provide limited facilities to distributekeys between different clients, although you must use an RFS for intermediate key storage. However,these utilities were originally designed for manual operation. Clearly, these utilities can be incorporatedinto automated scripts customized for your particular configuration. But elaborating this into anautomated system to distribute your keys without synchronization problems is a task for your systemdevelopment team. Further information about nCipher rfs-setup/rfs-sync utilities can be found in yourHSM User Guide.

An alternative for key distribution is the UNIX rsync utility. However, it is beyond the scope ofthis guide to discuss how this may be used.

If you require further assistance for distributed key update arrangements, please contact nCipherSupport, see https://www.ncipher.com/services/support/contact-support.

Local key storage and distribution implies:

l An explicit update mechanism that may be complex to automate

l Greater difficulty in keeping distribution time delays short, increasing any problems insynchronizing keys with data

l There are multiple copies of the Security World, making the loss of any one copy less significantthan may be the case with common storage.



E.1.3 Making a hardserver instance recognize new master keys

E.1.3 Making a hardserver instance recognize new master keys

In a configuration with multiple clients sharing the same encryption keys, if a rekey is performed, the newkeys should be immediately available and usable on the client that performed the rekey. However, for theother clients, after the new keys have been made available in their Security World folder, for the newkeys become usable to the local hardserver instance, you have a choice of the following options (thisapplies for both shared and local key storage):

1. In the nCipher ‘cknfastrc’ file for each client, insert the following:


This will ensure the Security World folder is scanned for the latest keys whenever a key is required,and avoids key caching. However, with this option the Security World will be scanned every time akey is required, even if no new keys have been added to the Security World. If there are many keysthis may take a significant time, and as it will be repeated every time a key is needed, may slowdown overall operations. However, use of this option should not require downtime for the keyupdate.

2. For each client that did not instigate a rekey, all applications/users that were using encryption keyson the database should be reconnected. A new connection will force a scan of the Security Worldthat will pick up new keys. But in this case, it is a single scan for that connection, and will NOT berepeated every time a key is required. If you have many keys, encrypted database operations willbe temporarily hindered only on the occasion you need to make a reconnection to update yourmaster keys. Use of this option may imply temporary downtime while reconnections are madeafter a key update. But if you routinely make new connections on your system per transaction, thisshould be hardly noticeable.

E.1.4 Other considerations

Even if for a short period a client is not able to access the required master keys, this may not necessarilybe a serious problem. The Oracle database should be able to recover gracefully if unable to obtain thecorrect master key(s). It should be possible to program the database to rollback failed transactions andmake several attempts to repeat the transaction, until some expiry point is reached.

If the delay in update of the master keys is short, then repeated attempts at the transaction shouldeventually succeed when the master key update is complete. If it is not possible to do this within theOracle database itself, then it should be possible to do something similar in the application code that isusing the database.

If you are using the common shared storage, it is expected that any lag in updating the master keys willbe short enough that either the Oracle database will not be affected, or else should cope gracefully, andsubsequently recover automatically as described above, as and when the update completes.

If delays in updating the master keys exceed the limits of what the Oracle database or application cancope with gracefully, then it may be necessary to halt encryption transactions temporarily while a masterkey rotation is performed.



We strongly recommend you test your solutions in a safe environment before transferring to a productionenvironment.


Appendix F How Oracle works with the nShield HSM

Appendix F How Oracle works with the nShieldHSMBefore using the nShield HSM, either a new Security World must be created using the HSM, or apreviously created Security World must be loaded onto the HSM. For more information, see the UserGuide for your HSM.

The Security World is stored in a folder on your host server(s) and holds the database encryption keys,and associated credential files, that are to be protected. All data in the Security World folder isautomatically encrypted and is useless to anyone without the authorized access and decryptionmechanisms. When encryption keys are to be used, they are loaded into the physically protectedenvironment of the HSM where they may be securely decrypted for use. Encryption keys protected by aHSM are never available in plaintext outside the boundary of the HSM. Legitimate use of the encryptionkeys is authorized and protected as described below.

If you are creating a new Security World, you must create an Administrator Card Set (ACS). An ACS is aset of physical smartcard(s) that must be used to create a Security World. When the Security World hasbeen created, the ACS is used to secure the higher administrative functions of the Security World.Without a quorum of ACS cards, you cannot create or load a Security World onto a HSM, or alter it. EachACS card can be issued with a unique passphrase and is specific to the Security World. When theSecurity World is created, you must stipulate a minimum number of cards, known as a quorum, requiredto load the Security World onto a HSM at any later time. However, the number of cards in the set shouldexceed the quorum, so that spares are available in case of failures or loss of card. An encrypted copy ofthe created Security World is stored in a folder on the host server(s).

If you are loading an existing Security World onto a HSM, you need access to a folder holding the SecurityWorld, and a quorum of the same ACS cards, and associated passphrase(s), that were used to create theSecurity World.

After the Security World has been created or loaded onto the HSM, a suitable HSM protection methodmay be prepared, or resumed if it was already present in an existing Security World. The protectionmethod enables authorized access to the encryption keys assigned to it. The following protectionmethods are available, in order of increasing authentication requirements:

l Module protection - Oracle master encryption keys are protected by a Security World protectingkey.

l Softcard protection - Oracle master encryption keys are protected by a (singular) named softwaretoken key, a passphrase, and Security World protecting key.

l Operator Card Set (OCS) protection - Oracle master encryption keys are protected by thepresence of a set of named physical token(s) or smartcard(s), an OCS token key, and SecurityWorld protecting key. An OCS smartcard set is similar to the ACS cardset in that it must stipulate aquorum of cards to authorize permission to use its protection. The number of cards in the setshould exceed the number of HSMs that may be sharing the same Security World so that sparesare available in case of failure. The card set should have a unique name that covers all cards in theset. In typical use with Oracle, all OCS cards in the same set should have the same passphrase,and the quorum is one.



For instructions to set up these protection methods, see the User Guide for your HSM.

If you have loaded an existing Security World onto the HSM and will be using an OCS cardset that italready contains, you must use the same physical OCS cards and associated passphrase(s) that wereoriginally created in that Security World. Similarly, for softcard or module protection, you will need theoriginal passphrase(s).

In this Integration Guide, the word credential is used for a passphrase, or the combination of apassphrase and a named token (OCS or softcard). Before an Oracle database can make use of thefacilities offered by the nShield HSM, it must have access to the ncipher library file (libcknfast.so) which isinstalled as described in this guide. This is vital, as without access to the ncipher library file, the Oracledatabase and nShield HSM or nCipher software cannot communicate. Once successful communicationis established between the Oracle database and nShield HSM, the Oracle database can gain access tothe HSM by use of a credential incorporated into an SQL script. When it is set up with a credential, theOracle database can proceed to create and assign encryption keys to that credential if no encryptionkeys yet exist, and encrypt or decrypt data using the encryption keys protected by that credential.

A protection method or credential is uniquely associated with the Security World where it was createdand cannot be used with any other Security World. It should also be uniquely associated with theencrypted database(s) it is protecting, but noting this could be more than one database. An encrypteddatabase cannot be decrypted without access to the same master keys that protect it (likely to be anasymmetric pair). If you use OCS protection, the Oracle database must use the correct OCS card nameand associated passphrase in its SQL scripts to access the encryption keys assigned to the OCS.Likewise, if you use a softcard, the Oracle database must use the correct softcard name and associatedpassphrase in its SQL scripts to access the encryption keys assigned to the softcard.

If you use module protection, a passphrase is required for the Oracle database access mechanisms only.The Oracle module protection passphrase does not have a reference or counterpart in the nShield HSM.This means that a user who is able to access keys directly in the HSM is able to access module protectedkeys for any database without requiring the Oracle passphrase. This does not apply for softcard or OCSprotection.

Use of the HSM credentials and associated SQL scripts that open up access to the encrypted data shouldbe strictly limited to authorized persons. However, the system can be set up so that approved clients canretrieve the encrypted data that is automatically decrypted when it leaves the database. Approveddatabase users do not need the HSM credentials and associated SQL scripts to do this. They cancontinue to use the database as normal. Encryption should be invisible to them in most circumstances.

If you first use an Oracle software keystore to protect the master encryption keys, but later wish to switchto a HSM, the encryption facilities can be migrated to the HSM. Also, encryption facilities can be migratedfrom a HSM back to an Oracle software keystore. During migration, fresh master key(s) are created inthe HSM or software keystore, and the subsidiary keys that are being protected are re-encrypted with thenew master key(s). Legacy keys remain in the software keystore or HSM where they were created, andshould be (securely) retained in case they were used for past backups or other legacy data. For moreinformation on key migration, see the Oracle documentation.

For loading or failover, you can use more than one HSM in the same system. The HSMs must share theSecurity World, and operate together to provide the same functions as a single HSM.



There is some performance degradation when Transparent Data Encryption (TDE) is used.The impact depends on the types of transactions you typically perform. Using the SecurityWorld software and the HSM usually have a negligible impact on TDE performance. Youshould test your Oracle and HSM configuration in a realistic test environment beforecommitting to a production environment.

All nShield HSMs are FIPS certified to 140-2 Level 3, meaning that they are tamper evident and tamperresistant. nShield Connects are also tamper responsive, if an attempt to open the nShield Connect bodyis detected, all stored HSM encryption key data is deleted.

The encryption facilities described in this document are designed only to protect data at rest. TDEencrypts data while stored on disk, but once the data is retrieved to working memory, it is in plaintext andcan be read by anyone able to access it. Decrypted data in transit between a database server and clientshould be independently encrypted to ensure security during data transfer. Security World data isinherently encrypted. There should be minimal security risk in transmitting this data over open networks.Similarly, encrypted database contents should be minimally at risk if transmitted over open networks.


Contact Us

Contact UsWeb site: https://www.ncipher.comSupport: https://help.ncipher.comEmail Support: [email protected] documentation: Available from the Support site listed above.

You can also contact our Support teams by telephone, using the following numbers:

Europe, Middle East, and Africa

United Kingdom: +44 1223 622444One Station SquareCambridgeCB1 2GAUK

Americas

Toll Free: +1 833 425 1990Fort Lauderdale: +1 954 953 5229

Sawgrass Commerce Center – ASuite 130,13800 NW 14 StreetSunriseFL 33323 USA

Asia Pacific

Australia: +61 8 9126 9070World Trade Centre Northbank WharfSiddeley StMelbourne VIC 3005Australia

Japan: +81 50 3196 4994Hong Kong: +852 3008 3188

10/F, V-Point,18 Tang Lung StreetCauseway BayHong Kong


About nCipher SecuritynCipher Security, an Entrust Datacard company, is a leader in the general-purpose hardware security module (HSM)market, empowering world-leading organizations by delivering trust, integrity and control to their business criticalinformation and applications. Today’s fast-moving digital environment enhances customer satisfaction, gives competitiveadvantage and improves operational efficiency – it also multiplies the security risks. Our cryptographic solutions secureemerging technologies such as cloud, IoT, blockchain, and digital payments and help meet new compliance mandates.We do this using our same proven technology that global organizations depend on today to protect against threats totheir sensitive data, network communications and enterprise infrastructure. We deliver trust for your business criticalapplications, ensure the integrity of your data and put you in complete control – today, tomorrow, always.www.ncipher.com

https://www.ncipher.com/

Oracle Database Integration Guide TDE... · 2020. 8. 3. · Page 2 of 98 Oracle Database -...

Documents

Transcript of Oracle Database Integration Guide TDE... · 2020. 8. 3. · Page 2 of 98 Oracle Database -...