Oracle Database Integration Guide · Solaris11.3.Oracle Solaris11.3couldnot betestedforkey...

Oracle DatabaseIntegration Guide Unix/Windows

Version: 1.10

Date: Tuesday, June 25, 2019

Copyright 2019 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 100 Oracle Database - Integration Guide Unix/Windows

Contents

1 Introduction 7

1.1 This Guide 7

1.2 Product configuration 8

1.3 Supported nCipher nShield functionality 9

1.4 Known Oracle bugs and patches 10

1.5 Conventions used in this document 12

1.5.1 Multitenant and non-multitenant 12

1.5.2 Database connections 12

1.5.3 Key migration and legacy keys 13

1.5.4 Importing keys 14

1.5.5 Bounce the database 14

1.5.6 UNIX/LINUX 14

1.5.7 Paths used 14

1.5.8 Common Criteria 15

1.6 More information 15

1.6.1 Contacting nCipher support 15

2 Overview 16

3 Installation and configuration 22

3.1 Supported platforms and environments 22

3.2 Preparatory requirements 22

3.3 Environment configuration 23

3.3.1 Oracle environment variables 23

3.3.2 Other uses of Oracle environment variables 26

3.3.3 nCipher environment variables 27

3.4 Basic setting up 28

3.5 Installing in an Oracle RAC configuration 32

3.5.1 Oracle RAC configuration using nShield Solos 33

3.5.2 Oracle RAC configuration using nShield Connects 35

3.5.3 Common Security World on RFS 36

3.5.3.1 Implementing the Common Security World on RFS configuration 38

3.5.4 Common Security World on shared disk 39

3.5.4.1 Implementing the Common Security World on shared disk configuration 42

Oracle Database - Integration Guide Unix/Windows of 100

3.6 Security Worlds, key protection and failure recovery 44

4 Configuring and Using nCipher Encryption Facilities 48

4.1 Latency issues 48

4.2 Storage and distribution of updated master keys 48

4.2.1 Common storage of master encryption keys 48

4.2.2 Local storage of master encryption keys 49

4.2.3 Making a hardserver instance recognize new master keys 50

4.2.4 Other considerations 50

4.3 Credential and passphrase recommendations 51

4.4 Configuring Oracle database software to use the nCipher HSM 53

4.5 Opening and closing a keystore or HSM 55

4.6 Migrating from a software wallet to a HSM 56

4.7 Migrating from a software keystore to a HSM 57

4.8 Creating master keys directly in a HSM for non-multitenant database 59

4.9 Creating master keys directly in a HSM for multitenant database 59

4.9.1 To create CDB and then all PDB master keys in one operation 60

4.9.2 To create CDB master key and a single PDB master key 60

4.9.2.1 To create CDB master key: 60

4.9.2.2 To create single PDB master key: 61

4.10 Checking the keystore or encryption keys 61

4.11 After you have migrated master keys to the HSM (non-multitenant) 62

4.12 Automatically open HSM at database restart (multitenant) 62

4.12.1 Setting up an auto-open keystore before any previous keystore exists 62

4.12.2 Setting up an auto-open keystore where a software keystore already exists 64

4.12.3 Setting up an auto-open keystore where no software keystore already exists 65

4.13 Rekeying or key rotation 67

4.13.1 Rekey when sharing keys between clients 67

4.13.2 Rekey for a non-multitenant database 68

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

4.13.4 Rekey for a multitenant database; CDB only 68

4.13.5 Rekey for a multitenant database; single PDB only 68

4.13.6 Rekey in a RAC cluster 69

5 Changing the HSM passphrase or credential 70


5.1 Change passphrase only 71

5.2 Change token with associated passphrase but keep same protection method 72

5.3 Change protection method 73

6 Using multiple Oracle database instances on the same host 76

7 nCipher Security World data and back-up 79

7.1 The local directory 80

7.2 Disaster recovery preparation 81

7.3 Backing up 82

8 Troubleshooting 84

Appendix A Setting up a Remote Shared Folder 87

A.1 Where the remote server is UNIX/LINUX based 87

A.2 Where the remote server is WINDOWS based 87

A.3 Where the local client is UNIX/LINUX based 88

Appendix B Example SQL scripts 90

B.1 CreateC##Tester.sql 90

B.2 CreateTester.sql 90

B.3 GrantTesterPrivileges.sql 91

B.4 CheckTesterPrivileges.sql 91

B.5 CheckEncryptionKeys.sql 92

B.6 CheckWalletState.sql 92

Appendix C Ghost data 93

D Glossary 94

Administrator Card Set (ACS) 94

Container Database 94

Close database 94

Common Criteria (CC) 94

Connection 94

Credential 94

Federal Information Processing Standards (FIPS) 94

Hardserver 94

Hardware Security Module (HSM) 94

ID 94

Key (encryption) 95


Key (wrapping) 95

Key migration 95

Key protector 95

Keystore (software) 95

Legacy key 95

Module 95

Module key 95

Multitenant 95

Non-container 96

Non-multitenant 96

Operator Card Set (OCS) 96

Open/Close database 96

Plaintext 96

Pluggable Database (PDB) 96

Remote Administration (RA) 96

Remote File System (RFS) 96

Security World 97

Security World data 97

Session 97

Softcard 97

Structured Query Language (SQL) 97

Transparent Data Encryption (TDE) 97

Trusted Verification Device (TVD) 97

Wallet (software) 98

Contact Us 99

Europe, Middle East, and Africa 99

Americas 99

Asia Pacific 99


1 Introduction

1 IntroductionThis guide describes how to integrate and use nCipher Security Security World software (or SecurityWorld software) and nCipher Security nShield Hardware Security Modules (or HSMs) with an Oracledatabase. This provides data-at-rest encryption for sensitive information held by the Oracle database.Both multitenant 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.

Integrated Oracle and nCipher technology has been tested to support Oracle Transparent DataEncryption (TDE) for tablespace encryption and TDE column encryption (and both concurrently). nCiphernShield HSMs are certified to FIPS 140-2 (level 3) to deliver a high grade of security assurance.Functionality includes protection of sensitive encryption keys and support for offload of encryption andkey management operations.

1.1 This GuideThis Integration Guide covers UNIX/LINUX and WINDOWS based systems.

The guide is focused on showing how to configure the integration between the nCipher Security Worldsoftware and HSM, and Oracle database technology. 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

existso Configure the Oracle database software to use the HSM in the context of multiple database

instances running on the same host. This includes the ability to mix software keystore andHSM usage at the same time.

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. This guide does NOT tellyou how to:

l Install Oracle software

l Create an Oracle database


1 Introduction

l Set up an Oracle RAC cluster

l Set up an Oracle software keystore (or Oracle software wallet).

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 ofachieving 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, please contact nCipher Security 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

nShieldSecurityWorldsoftwareversion

Oracledatabaseversion

Tested withnShield SoloHSM version

Tested with nShield ConnectHSM version

Windows Server 2016Datacenter 12.60 12.2.0.1.x Solo, Solo+,

SoloXC Connect, Connect+, ConnectXC

Oracle Linux 7.2 12.40.2 12.2.0.1.x Solo, Solo+,SoloXC Connect, Connect+, ConnectXC

Oracle Linux 7.2 12.40.2 12.1.0.2.x Solo, Solo+,SoloXC Connect, Connect+, ConnectXC

Oracle Linux 7.2 12.40 12.1.0.2.x Solo, Solo+ Connect, Connect+

Oracle Linux 7.2 12.30 12.1.0.2.x Solo, Solo+ Connect, Connect+


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

1.3 Supported nCipher nShield functionality

Operating system

nShieldSecurityWorldsoftwareversion

Oracledatabaseversion

Tested withnShield SoloHSM version

Tested with nShield ConnectHSM version

Oracle Linux 7.2 12.10.01 12.1.0.2.x Solo, Solo+ Connect, Connect+

Oracle Solaris 11.3x86_64 12.10.01 12.1.0.2.x Solo, Solo+ Connect, Connect+

Red Hat EnterpriseLinux 7.2 12.10.01 12.1.0.2.x Solo, Solo+ Connect, Connect+

Oracle Linux 7.2 12.30 11.2.0.2.0 Solo, Solo+ Connect, Connect+

Oracle Linux 7.2 12.10.01 11.2.0.1.0 Solo, Solo+ Connect, Connect+

Red Hat EnterpriseLinux 6 11.70 11.2.0.4.0 Solo, Solo+ Connect, Connect+

Red Hat EnterpriseLinux 6 11.60 11.2.0.3.0 Solo, Solo+ Connect, Connect+

It is not always possible to update the list of tested configurations immediately after a newOracle Database version, or patch is released. If a configuration is not listed here, this does notnecessarily imply the configuration has not been tested, or is not supported, or will not work.

If a configuration is not listed above and you require more explicit information about testedconfigurations, or are having configuration problems, please contact nCipher support, seehttps://www.ncipher.com/services/support/contact-support

You should always test your configuration in a safe environment before committing to aproduction environment.

Oracle RAC (or cluster) integration was tested using a two-node cluster with shared disk.

1.3 Supported nCipher nShield functionality

Function Support

Key Generation Yes

Key Management Yes

Key Import No

Key Recovery Yes

1-of-N Operator Card Set Yes



1 Introduction

Function Support

K-of-N Operator Card Set No

Softcards Yes

Module-only Key Yes

FIPS 140-2 Level 3 Support Yes

Load Sharing Yes

Fail Over Yes

Do not confuse Key import with Key migration, see Keymigration and legacy keys onpage 13

1.4 Known Oracle bugs and patchesTo obtain more information about the latest available Oracle patches as appropriate to your system,please contact Oracle support at https://www.oracle.com/support/index.html. You may require an Oraclesupport contract in order to be able to gain further information about, or download, Oracle patches.

OraclePatchID

Oracle Ver-sion

OS Version Bugs fixed Bug symptoms/notes

12118360 11.2.0.1.0 UNIX/LINUX8909973:TDE cannot support multi-token HSMs.

1123404322 11.2.0.2.0 UNIX/LINUX 9034189: TDE withHSM race condition.

23528412 12.1.0.2.0 Linux-x86-6423528412: Heartbeatclosing HSM erroneously

23528412: Causesloss of authorizationfor persistent OCScards.

At time of our testing,no patches wereavailable for Oraclebug 23528412 onOracle Solaris 11.3.Oracle Solaris couldnot be tested for keymigration or persistentOCS cards.


https://www.oracle.com/support/index.html

1.4 Known Oracle bugs and patches

OraclePatchID

Oracle Ver-sion

OS Version Bugs fixed Bug symptoms/notes

25063460 12.1.0.2.0 Linux-x86-64

Merged patch:17409174: 12C: TDE_MASTER_KEY is notset in PDB after keymigration, or reversekey migration, withHSM. 23528412:Heartbeat closingHSM erroneously

17409174: Cannotsuccessfully migrateencryption keysbetween keystore andHSM. 23528412:Causes loss ofauthorization forpersistent OCS cards.

At time of our testing,no patches wereavailable for Oraclebugs 17409174,23528412 on OracleSolaris 11.3. OracleSolaris 11.3 could notbe tested for keymigration or persistentOCS cards.

21080143 12.1.0.2.0 Linux-x86-64

21080143:ORA‐00600 [KSQGELNULL_PARENT]WITH ENCRYPTEDTABLESPACES

21080143: Occasionally generatesORA-00600 internalerror code.

20842388 12.1.0.2.0 Linux-x86-64

20842388: AUTO-LOGIN HSMSUPPORT FORPDBS

20842388: Auto-loginwith HSM doesn’twork.

nCipher is not responsible for any ongoing updates to Oracle software that may make the aboveinformation obsolete. If in doubt, we always recommend you use the latest patches from Oracle that arerelevant to your configuration and do not conflict with your nCipher integration.

You will need the Oracle Opatch utility to install patches, and must use the appropriate version.

For Oracle database versions 12.1.x on Linux-x86-64 platforms the following Opatch software can beused:

l p6880880_121010_Linux-x86-64

For definitions used throughout please refer to theGlossary on page 94.


1 Introduction

1.5 Conventions used in this document

1.5.1 Multitenant and non-multitenantDescriptions 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.

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.5.2 Database connectionsYou 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. Example SQL scripts to create users and privileges for use in this document areprovided in Example SQL scripts on page 90.

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:


1.5.3 Key migration and legacy keys

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

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 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$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 PDB<k>TESTER@CDB<n>PDB<k>

1.5.3 Key migration and legacy keysEncryption 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.

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. If


1 Introduction

you are using both a software keystore and HSM at the same time, whichever is the current key protectoris called the primary.

It is Oracle’s policy that you should retain your legacy keys indefinitely. If you wish to delete them, pleasecontact Oracle support.

1.5.4 Importing keysIf by importing keys we mean importing a foreign key created independently and externally to the HSMinto its Security World, it is not recommended to import such keys unless they are from a trustworthysource. Importing of externally created keys into the Security World may require format conversion. OnlyPKCS11 keys are supported.

nCipher provides limited off the shelf key import facilities through use of the generatekey utility orKeySafe application. No key export facilities are supplied.

However, there is no known means to import legacy keys from an Oracle software keystore into a HSMat time of writing this guide. You must retain access to the software keystore to continue using legacykeys it contains, seeChapter 1: Configuring andUsing nCipher Encryption Facilities on page 1, formethods to retain access to legacy keys. Please contact nCipher support if you wish to pursue keyimport (or export) operations, see https://www.ncipher.com/services/support/contact-support.

1.5.5 Bounce the databaseThis means restarting the database, and is normally done through the sqlplus interface, for example:

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup;

ORACLE instance started.

Total System Global Area 6593445888 bytes

Fixed Size 3725656 bytes

Variable Size 3657434792 bytes

Database Buffers 2919235584 bytes

Redo Buffers 13049856 bytes

Database mounted.

Database opened.

1.5.6 UNIX/LINUXIn this document ‘UNIX’ will be taken to cover ‘LINUX’ functionality unless otherwise stated.

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



1.5.8 Common Criteria

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

1.5.8 Common CriteriaUnless stated otherwise, please treat a Common Criteria Security World configuration the same as aFIPS 140-2 Level 3 Security World configuration.

1.6 More informationl For more information about Oracle, contact your Oracle sales representative, or Oracle support at:

https://www.oracle.com/support/index.html.

l For more information about using Oracle database TDE, see:https://docs.oracle.com/database/121/ASOAG/toc.htm.

l For more information on administering an nShield module, see the accompanying User Guide.Additional documentation produced to support your nCipher nShield product is in the documentdirectory of the supplied media for that product.

1.6.1 Contacting nCipher supportTo obtain support for your product, visit https://www.ncipher.com/services/support/contact-support.


https://www.oracle.com/support/index.html

https://docs.oracle.com/database/121/ASOAG/toc.htm


2 Overview

2 OverviewThis chapter provides an overview of how Oracle Transparent Database Encryption (TDE) operates, howan nShield HSM helps to protect Oracle database master encryption keys, plus some of the othersecurity benefits of using an nShield HSM and associated nCipher Security World software.

Encryption should be part of a wider process of implementing security best practices to protect yourdatabase assets which also takes into account any regulatory or legal requirements for data protection.Administration and management of encryption within any organization is a serious issue that requiresappropriate training and resources. Applying encryption by itself may not necessarily provide the overallsecurity solution you need; you should seek guidance from accredited computer security professionals todevelop security practices appropriate to your whole requirements.

The encryption schemes here are designed only to protect data at rest. Data in transit between adatabase server and client should be independently encrypted to ensure security during data transfer.

An Oracle database allows a user to create tablespace(s) to store database objects. A tablespaceincludes one or more data files that conform to the underlying file system of the operating system.Relational database tables that are created by the user are stored across one or more of the data fileswithin a tablespace. The data files that store the relational table data can be located and inspected ondisk, for cases where the user may wish to manually check if those files are encrypted. Also, seeGhostdata on page 93.

Before you can begin encryption of an Oracle database, you must either create an Oracle softwarekeystore, or else set up a HSM, to store the master encryption keys that will be required. Encryption keystorage and protection is explained in more detail later.

The Oracle database provides two modes of encrypting data stored within the data files on disk, asdescribed below:

l Tablespace encryption is used to encrypt all data within the selected tablespace. There is achoice of encryption algorithms that can be used, and the selected algorithm will be used toencrypt the entire tablespace. If a tablespace is encrypted, then all data submitted into it isautomatically encrypted as it is written to disk, and all data read back out of it is automaticallydecrypted as it is retrieved back into memory.

l Column encryption is used to encrypt the data in one or more columns of a selected table. Thereis a choice of encryption algorithms you can select, but you must use the same algorithm for allcolumns you wish to encrypt within the same table. You can start with a non-encrypted table, andencrypt columns later. You can also switch off the encryption (per column) and return a column toplaintext if you wish. If all columns are decrypted, it is possible to re-encrypt columns using adifferent encryption algorithm. All data submitted to an encrypted column is automaticallyencrypted as it is written to disk, and all data read back from an encrypted column is automaticallydecrypted as it is retrieved back into memory.

When using TDE, database backups are encrypted in a similar fashion to the corresponding database,and must have access to the same encryption keys to allow decryption. Both Tablespace encryption andColumn encryption can be used together, in which case the column encrypted columns will be encryptedtwice when stored on disk.


2 Overview

Figure 2.1 How Oracle encryption keys are stored and protected


2 Overview

There are restrictions on using the above encryption methods. For example, you cannotencrypt columns used in foreign key constraints. A full description of all restrictions is beyondthe scope of this document. Please refer to the Oracle literature for more information aboutthese restrictions.

The process by which data is automatically encrypted when written to disk, and automatically decryptedas it is read back into memory, is called Transparent Data Encryption (TDE). It is transparent because,barring the restrictions referenced above, the user can continue to use the database as if the encryptionwas not there.

TDE encrypts data while stored on disk, but once the data is retrieved to working memory, it isin plaintext and can be read by anyone able to access it.

In order to use TDE you must configure an Oracle software keystore or a HSM. You then needto establish the tablespace or column encryption using SQL directives. There is no mechanismindependent of this to switch TDE on or off. Column encryption can be switched off (decrypted)using appropriate SQL directives. But tablespace encryption cannot be switched off in thisway. If you wish to decrypt a table within an encrypted tablespace, you must move it into aseparate unencrypted tablespace.

There is some performance degradation when using TDE. How significant this is depends on the types oftransactions you perform. Please refer to the Oracle literature for a fuller description of performanceimpact. Use of nCipher Security World software and HSM will usually make a negligible impact on TDEperformance, depending on the transaction types being performed. You should test your TDEarrangements for any statistically significant performance degradation in typical usage scenarios, beforecommitting to your production environment. If performance degradation is found to be unacceptable,please contact Oracle support first (in the event that the nCipher HSM is affecting performance, pleasecontact nCipher support, see https://www.ncipher.com/services/support/contact-support).

Referring toHow Oracle encryption keys are stored and protected on page 17, we can see a simpleexample of how the encryption keys are stored and protected. The encryption keys that are directly usedto perform tablespace encryption, or column encryption, are stored with the database itself. They are notstored in plaintext however, and are themselves encrypted by a TDE master key held in a softwarekeystore or HSM. Normally, for column encryption there will be one table encryption key for each tablethat uses column encryption, and these table encryption keys will be stored in the data dictionary of thedatabase. These keys are encrypted and protected by the TDE master key held in the software keystoreor HSM. For tablespace encryption there will normally be one tablespace encryption key for eachencrypted tablespace. A tablespace encryption key is in turn encrypted and protected by the TDE masterkey held in the software keystore or HSM.

The TDE master key must be created before the table or tablespace keys can be created within thedatabase. This in turn requires that an Oracle software keystore or HSM have first been set up andcorrectly configured to hold the TDE master key. The TDE master key is created using SQL directives.

The description given so far applies for encryption on non-multitenant databases. For multitenantdatabase the basics are essentially the same, except in this case you have a container database (CDB)



2 Overview

that holds zero, or up to 253 pluggable databases (PDBs). Here, the CDB, and every PDB whereencryption is required, must have a TDE master key. The master key for the CDB must be created first,followed by a master key for each PDB where encryption is to be used.

A PDB master key can be created individually for each PDB, or else master keys can be created for allthe PDBs in a bulk operation. Again, the master keys are created using suitable SQL directives. Thekeystore or HSM will hold the CDB master key and all the PDB master keys.

If you are using more than one database instance on the same host, then usually each database instancewill have its own private keystore. However, if using an nShield HSM, there can be only one hardserverinstance per host, and all database instances will have to use the same nShield HSM, seeUsingmultipleOracle database instances on the same host on page 76.

An Oracle software keystore is held in a file separate from the database it is protecting. The file is itselfprotected by a passphrase and permissions settings, or it can be auto-login with an embeddedpassphrase so that the keystore opens automatically with the database startup.

Assuming the Oracle master key(s) are secured using a nCipher HSM, obviously the nCipher SecurityWorld software and associated HSM must be installed. Interfacing between the nCipher Security Worldsoftware and Oracle database requires some basic configuration, with intercommunication using a(single) library API provided by nCipher. An nCipher Security World must be created and loaded into theHSM, and a suitable HSM protection method must also be prepared, before encryption keys can becreated and encryption may begin.

Before using the HSM, either a new Security World must be created using the HSM, or else a previouslycreated Security World must be loaded onto the HSM.

If creating a new Security World, you must also create an Administrative Card Set (ACS). An ACS is a setof physical smartcard(s) that must be used to create a Security World. Each ACS card can be issued withits own (unique) passphrase and is specific only to the Security World being created. At time of creationyou must stipulate a quorum (or minimum number) of cards required to load the Security World onto aHSM at any later time. However, the number of cards in the set should exceed the quorum, so that sparesare available in case of failures. An encrypted copy of the created Security World is stored in a folder onthe host, see Section 7.0 for more information.

If you are loading an existing Security World onto a HSM, you will require access to a folder holding theSecurity World, and a quorum of the same ACS cards (and associated passphrase(s)) used to originallycreate the Security World.

The ACS cards are used to secure the higher administrative functions of the Security World. They mustbe stored securely, and with access restricted to authorized users. Without a quorum of ACS cards, youcannot create or load a Security World onto a HSM, or alter it.

After the Security World has been created or loaded onto the HSM, a suitable HSM protection methodmust be prepared.

The protection methods available with the nCipher HSM are, in order of enhanced authentication:


2 Overview

l module protection, where Oracle master keys are protected by a Security World protecting key

l softcard protection, where Oracle master keys are protected by a named softcard (or software)token key, a passphrase, and Security World protecting key

l Operator Card Set (OCS) protection, where Oracle master keys are protected by thepresence of a set of named physical token(s) (or smartcard(s)), an OCS token key, and SecurityWorld protecting key. Similar to the ACS cardset, an OCS smartcard set must stipulate a quorum ofcards to authorize permission to use its protection. Each card in the set can have its own uniquepassphrase. The number of cards in the set should exceed the quorum so that spares areavailable in case of failure.

If you use OCS protection, then this must be set up in the nCipher Security World with an OCS card nameand associated passphrase. To reference the particular OCS card (or token) required, and thereby createor access its TDE master key(s), the Oracle database must use the correct card name and associatedpassphrase in its SQL scripts. Things are similar for softcard protection, but not quite the same for moduleprotection, as explained shortly.

For the purpose of this document, a passphrase, or combined passphrase and token (OCS or softcard),as used by the Oracle database to access the nCipher Security World and HSM, is referred to as acredential. If you have multiple database instances on the same host, using the same HSM, eachinstance can use a different protection method, or the same protection method with a different credential,thereby isolating each database’s encryption keys from access by any other database.

If using 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 nCipherHSM. This means a user who is able to access keys directly in the HSM will be able to access moduleprotected keys for any database without requiring the (Oracle) passphrase. This does not apply forsoftcard or OCS protection.

While we may use the singular term HSM, in practice for loading or failover purposes you can use morethan one HSM if correctly configured. But these must share the same Security World, and will operate toprovide the same functions as for a single HSM.

All Security World derived keys are stored as application key tokens (encrypted blobs) in the SecurityWorld data folder of the requesting client server. The key tokens can only be decrypted for use in an HSMthat shares the correct Security World master (module) key. Cryptographic data held in Security Worlddata folder is inherently encrypted. Therefore, although it may be visible to anyone with access to theSecurity World folder on the host server, the cryptographic material is unusable without a nCipher HSM,Security World software, and the correct authorizing mechanisms to load the data onto the HSM, andpermit use of the keys. For more information about the Security World folder, see nCipher SecurityWorlddata and back-up on page 79.

All nShield hardware is 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.

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 in


2 Overview

the HSM or software keystore, and the subsidiary keys that are being protected are re-encrypted with thenew master key(s). Legacy keys will remain in the software keystore or HSM where they were created,and should be (securely) retained in case they were used for past backups or other legacy data. For moredetails, see Keymigration and legacy keys on page 13.

Apart from the robust physical security provided for the encryption keys, advantages of using the nCipherSecurity World software and HSM are support for encryption acceleration, and enhanced facilitiesdedicated to the generation, back up, management and secure protection of the encryption keys. Thesefacilities become more important as the amount of encrypted data, and the number of encryption keys,increases.

Other benefits of using the nCipher Security World software and HSM include:

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

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

l Reduced costs of regulatory compliance

l FIPS certification

l Common criteria certification.

If Security World data (or encryption keys) are lost, they can be securely recovered from a backup asauthorized through secure administrative means. However, it is important to maintain an up-to-datebackup of your database and the corresponding nCipher Security World files.

When use of encryption keys is legitimately made available to the database, the continuingsecurity of data protected by those keys becomes dependent on access offered through theOracle database in accordance with your organisation’s security policies.

Security World data is inherently encrypted, see section 7.0. There should be minimal securityrisk in transmitting this data over open networks. Similarly, encrypted database contentsshould be minimally at risk if transmitted over open networks. However, in networkedconfigurations that carry such data, you may wish to enhance security by encryptingcommunication links.


3 Installation and configuration


3.1 Supported platforms and environmentsPlease refer to the Product configuration on page 8 for information about supported platforms andenvironments.

3.2 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.

If you are running multiple database instances on the same host, or are planning to do so, we stronglyrecommend you first readUsingmultiple Oracle database instances on the same host on page 76.

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 shouldspecify the following aspects of HSM administration:

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

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 wish 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.

If you wish to run more than one database instance on the same host, you canuse a different protection method for each database, or the same protectionmethod but using different credentials (passphrase/token). However, beforeattempting this, seeUsingmultiple Oracle database instances on the same hoston page 76.

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

l You need to create a policy for managing the passphrases for your:



o ACSo Module protectiono Softcard protectiono OCS protection.

l You need to create a policy for managing the physical security of your smartcards as used for ACSand OCS, and their deployment to authorized users

l You must decide whether you wish to use the facilities offered by using nCipher V12 softwareRemote Administration (RA) facilities.

We do not recommend use of RA where you desire automatic recovery from a temporary system failure.Please see SecurityWorlds, key protection and failure recovery on page 44.

This guide assumes that Oracle database software, and (at least) one Oracle database, is alreadyinstalled on your system. With Oracle database software already installed, see KnownOracle bugs andpatches on page 10 to ensure that any required patches 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 multiple database instances on the same host

l Are using an Oracle RAC cluster.

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

3.3 Environment configuration

3.3.1 Oracle environment variablesIf your Oracle database software is already installed, it is assumed that within your operating systemenvironment you already have:

l An oracle user

l (Unix/Linux only) dba, and oinstall user groups.

The following bullet points describe important Oracle environment variables that need to be consideredwhen configuring a system. Later examples shown in this guide are based on the values shown here. If


3.3.1 Oracle environment variables

you already have Oracle database software and database(s) installed, these environment variables mayalready be set. In a Windows system the variables are usually already set in the registry. In a UNIXsystem the variables are expected to be set in the ‘oracle’ user environment. Some of these environmentvariables may not apply in a RAC cluster environment. In this case please adapt the examples shown inthis guide to your own environment.

For more details about Oracle environment variables please see,https://docs.oracle.com/database/121/UNXAR/admin_ora.htm#UNXAR001.

Environment Variables and Descriptions:

l ORACLE_BASE

Used as the root, or base, for the Oracle installation. Examples:

UNIX:

ORACLE_BASE=/opt/oracle

ORACLE_BASE=/opt/oracle12c

ORACLE_BASE=/opt/oracle11g

WINDOWS:

ORACLE_BASE=C:\app\oracle

ORACLE_BASE=C:\app\oracle12c1

ORACLE_BASE=C:\app\oracle12c2

l ORACLE_HOME

Points to the directory where the database operational software, NOT the actual database file(s), isstored. For example:

UNIX:

ORACLE_HOME=$ORACLE_BASE/product/<Oracle-version>/dbhome_1

WINDOWS:

ORACLE_HOME=%ORACLE_BASE%\product\<Oracle-version>\dbhome_1

l ORACLE_SID

Used as the name of a particular database instance on the system. If you have more than one databaseon the same host, then the value of ORACLE_SID must be unique within the local environment for eachdatabase instance. Note, for multitenant database(s), an instance will refer to a single containerdatabase. Examples:

Non-multitenant:

ORACLE_SID=DB12c1, as instance for Oracle 12c1 database

ORACLE_SID=DB11g1, as instance for Oracle 11g1 database

Multitenant:


https://docs.oracle.com/database/121/UNXAR/admin_ora.htm#UNXAR001


ORACLE_SID=CDB1, as instance for CDB1 container database

ORACLE_SID=CDB2, as instance for CDB2 container database

l PATH

The usual system PATH environment variable, but which must include the path to the databaseutilities for them to work in the environment, for example:

UNIX:

PATH=$PATH:$ORACLE_HOME/bin

WINDOWS:

PATH=%PATH%;%ORACLE_HOME%\bin

l TNS_ADMIN

Points to the directory where the net configuration files are kept (sqlnet.ora, listener.ora andtnsnames.ora). May not apply in the case of a RAC cluster, see"Installing in an Oracle RACconfiguration" on page 32’

The net configuration files are important to configure your database to communicate with the outsideworld, including the nShield HSM. Example (TNS_ADMIN default):

UNIX:

TNS_ADMIN=$ORACLE_HOME/network/admin

WINDOWS:

TNS_ADMIN=%ORACLE_HOME%\network\admin

If you require only a single database instance on your host server, you can use the default location forTNS_ADMIN.

If you are using multiple database instances on the same host server, then each database instanceshould have its own keystore. See ‘"Using multiple Oracle database instances on the same host" onpage 76’. In this case, if at some future time you are planning to migrate keys from ALL the softwarekeystores to a HSM as part of the same process, you can also use the same default TNS_ADMIN locationfor every instance.

If you are using multiple database instances on the same host server, and if at some future time you areplanning to migrate keys from only some software keystores to a HSM, that is you want a mixture,keeping some database instances protected by a their software keystore, but other database instancesprotected by a HSM, then you should plan to have a unique path for the TNS_ADMIN variable for eachdatabase instance environment. In the following examples, ORACLE_SID makes a unique path for eachinstance:

UNIX:

TNS_ADMIN=$ORACLE_BASE/$ORACLE_SID/tnsadmin

WINDOWS:


3.3.2 Other uses of Oracle environment variables

TNS_ADMIN=%ORACLE_BASE%\%ORACLE_SID%\tnsadmin

On a stand-alone system the 'tnsadmin' folder will contain the sqlnet.ora, listener.ora and tnsnames.orafiles respective to each database instance. For RAC clusters, please study your own configuration forlocation of these files.

For more information on dealing with multiple instances, please the sectionUsingmultiple Oracledatabase instances on the same host on page 76.

3.3.2 Other uses of Oracle environment variablesOther uses of Oracle environment variables you should be aware of are as follows.

The ORACLE _SID name is typically used to install the database files it will reference for a particulardatabase instance. The actual database instance files are usually located at:

UNIX:

$ORACLE_BASE/oradata/$ORACLE_SID

WINDOWS:

%ORACLE_BASE%\oradata\%ORACLE_SID%

The ORACLE _SID name is typically used to install the software wallet or software keystore files it willreference for a particular database (hence, if you have multiple database instances on the same host,each will have its own software wallet or software keystore). These are usually located at, for example:

UNIX:

[Non-multitenant] $ORACLE_BASE/admin/$ORACLE_SID/wallet-folder

[Multitenant] $ORACLE_BASE/admin/$ORACLE_SID/keystore-folder

WINDOWS:

[Non-multitenant] %ORACLE_BASE%\admin\%ORACLE_SID%\wallet-folder

[Multitenant] %ORACLE_BASE%\admin\%ORACLE_SID%\keystore-folder

May not apply for Oracle RAC cluster.

You will normally create the terminating folder before creating the actual wallet orkeystore.

If your backup system uses $ORACLE_BASE to determine the root for backups, you maywish to place your software wallet or software keystore under a different root so yourencryption keys and data are not backed up in the same package.



3.3.3 nCipher environment variablesThe nCipher Security World environment variables are independent of, and are not affected by, theOracle installation. The following nCipher environment variables are relevant here:

l NFAST_HOME

The root directory for all of the nCipher Security World software, data, configuration files and suppliedutilities. Usually:

UNIX:

NFAST_HOME = /opt/nfast

WINDOWS:

NFAST_HOME =C:\Program Files (x86)\nCipher\nfast

l NFAST_KMDATA

Points to the directory that contains all the nCipher Security World configuration information. Usually:

UNIX:

NFAST_KMDATA = $NFAST_HOME/kmdata

WINDOWS:

NFAST_KMDATA = C:\ProgramData\nCipher\Key Management Data

l NFAST_KMLOCAL

Points to the specific folder containing the nCipher Security World (cryptographic) data. This can be set upto be on a remote server other than the host server running the database. See later configurations.

UNIX:

NFAST_KMDATA = $NFAST_HOME/kmdata/local or

NFAST_KMLOCAL=<remote-server-name>/local

WINDOWS:

NFAST_KMDATA = C:\ProgramData\nCipher\Key Management Data\local or

NFAST_KMLOCAL=<remote-server-name>\local

If you do not use NFAST_KMLOCAL, the nCipher Security World data folder will automatically default toNFAST_KMDATA/local on the host server. You do not need to use NFAST_KMLOCAL unless you want toreference the Security World data folder at some place other than NFAST_KMDATA/local on the hostserver.

l PATH

To use the nCipher supplied utilities, set the following in your PATH:


3.4 Basic setting up

UNIX:

PATH=$PATH:$NFAST_HOME/bin

WINDOWS:

PATH=%PATH%;%NFAST_HOME%\bin

For more information on nCipher environment variables, see your HSM User Guide.

3.4 Basic setting upNormally a client server will be the host server that your Oracle database is running on. In a RAC cluster,each node is a client server.

It is only possible to run one nCipher hardserver instance on the same client. However, if you are runningmultiple database instances on the same client, the one hardserver instance will cater for all databaseinstances on that client.

If using an RAC cluster, each node will run its own nCipher hardserver instance and its own copies of thedatabase instances running on the cluster. This implies you must take some care that each node isreferencing the same Security World encryption keys if it is to handle the same encrypted databaseinformation.

Instructions in this section are for a basic set-up and should be adequate for a non-RAC clusterenvironment. Apply these instructions to each client, and RFS, you are setting up. However, if you areusing an RAC cluster environment, please read all further sections in this chapter before attempting theset-up. These further sections detail how the set-up needs to be modified for an RAC cluster, dependingon your requirements.

Uninstall and delete any pre-existing nShield software from your host client(s) and RFS, beforeproceeding with the set-up. (Adjust folder paths as appropriate to your UNIX or WINDOWS hostenvironment.)

Please read the User Guide for your HSM if you require further details on how to complete the followinginstructions.

1. If you are using nShield Solo(s), physically install them in your host server using the instructions inthe 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 server in accordance with itsaccompanying documentation. If you are using nShield Connects with a separate RFS, the nCipherSecurity World software must also be installed on the RFS.

If you are using separate client(s) and RFS, you can use either a UNIX/LINUX or aWINDOWS based RFS



3. Create or edit the cknfastrc file located in the NFAST_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 loadsharing:

CKNFAST_LOADSHARING=1

Including module key protection:

CKNFAST_FAKE_ACCELERATOR_LOGIN=1

If using a RAC cluster or distributed local Security Worlds, you may consider using the followingenvironment variable. But first, see "Configuring and Using nCipher Encryption Facilities" on page 1to understand the full consequences:

CKNFAST_ASSUME_SINGLE_PROCESS=0

These are the minimum PKCS #11 library environment variables you will need for examples in thisdocument. However, there are more variables available than shown here. For more information,please study the PKCS #11 library environment variables in the User Guide for your HSM. Astuteuse of these variables can allow you to configure your security environment very precisely.

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 the followingdirectory 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: (For 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\]


3.4 Basic setting up

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

The [/hsm-manufacturer/library-version/] extensions are normally optional. You can use the ncversionsutility to find the library-version number for the pkcs11 library.

Valid directory examples are:

UNIX:

[32 bit] /opt/oracle12c1/extapi/32/hsm/

[64 bit] /opt/oracle12c2/extapi/64/hsm/nCipher/v12.40/

WINDOWS:

[32 bit] C:\oracle\extapi\32\hsm\

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

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 (x86)\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 apprpriate for your OS architecture to the folder that was preparedin step 5. Remove (any) [-32|-64] suffix from the copied file. For example:

UNIX:

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

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

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

Alternatively, you can create a link to libcknfast.so:

Using link ‘=>’:

[32 bit] $ORACLE_BASE/extapi/32/hsm/ => /opt/nfast/toolkits/pkcs11/libcknfast.so

[64 bit] $ORACLE_BASE/extapi/64/hsm/ => /opt/nfast/toolkits/pkcs11/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\cknfast.dll

[32 bit] C:\oracle\extapi\32\hsm\cknfast.dll

[64 bit] C:\oracle\extapi\64\hsm\nCipher\v12.40\cknfast.dll

Alternatively, you can create a link to cknfast.dll:

Using link ‘=>’:

[32 bit] C:\oracle\extapi\32\hsm\ =>

C:\Program Files (x86)\nCipher\nfast\toolkits\pkcs11\cknfast.dll

[64 bit] C:\oracle\extapi\64\hsm\nCipher\v12.40\ =>

C:\Program Files (x86)\nCipher\nfast\toolkits\pkcs11\cknfast.dll

Make sure the ‘oracle’ user can access the cknfast.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. If you are using nCipher V12 software with Remote Administration, your HSM(s) must bewarranted, and a single cardlist file must be present and configured. Do not forget to set up thedynamic slots. For details, see the User Guide for your HSM.

9. Create or load the desired Security World using a client, or nShield Connect (if being used). If 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.

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

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:


3.5 Installing in an Oracle RAC configuration

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

l If using nCipher V12 software, on the client run the nCipher utility ‘nethsmadmin’:

>>nethsmadmin -c -module number

The Security World must be shown as ‘Initialized’ and ‘Usable’. For further details please see the Userguide for your HSM.

11. According to the protection method(s) you wish to use, proceed as follows:

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), each with itsown 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.

SeeCredential and passphrase recommendations on page 1

12. If you are using module or softcard protection within a FIPS 140-2 Level 3 or Common Criteriaenvironment, then you will also need an OCS cardset (1/N) to provide FIPS or Common Criteriaauthorization. Create the cardset. If only needed for FIPS or Common Criteria authorization, apassphrase is not used. However, just in case the OCS cards become used for other purposes, wesuggest you treat these as any other OCS cardset, and give the exact same passphrase for eachcard.

13. If you are using nCipher V12 software with Remote Administration under OCS protection, insertOCS cards, and establish remote connections to every HSM you are using. If you are using V11OCS cards, or V12 OCS cards but don’t want to use Remote Administration, insert an OCS cardinto the card readers of every HSM you are using.

3.5 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, please 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 28,but there are important differences in how you reference your Security World data, or locate your Oraclenet configuration files.

The Oracle net configuration files on each node need to be the same. It is important that the sqlnet.ora fileon each node is identical if performing key migration from a software keystore to HSM, or using a HSMand software keystore together, or setting up to use a HSM only. Typically, as the net configuration filesare unlikely to change after initial configuration, it may be satisfactory to copy the same files to theappropriate local directories on each node. On the other hand, you may wish to use a common sharedcopy of these files by using the TNS_ADMIN variable on each node to point to a common location on ashared disk system.



If using V12 software and smartcards, the cardlist file, must be identical on each node, that is:

l UNIX: /opt/nfast/kmdata/config/cardlist

l WINDOWS: C:\ProgramData\nCipher\Key Management Data\config\cardlist

See your HSM User Guide for details of how to set up the cardlist file.

In the cknfastrc file for each RAC cluster node, you may consider including the following environmentvariable. But first, see Latency issues on page 1 to understand the full consequences:


All cluster configurations shown in this guide, inOracle RAC configuration using nShield Solos on page34,Oracle RAC configuration usingCommon SecurityWorld on RFS on page 37 andOracle RACconfiguration usingCommon SecurityWorld on shared disk on page 41, use a common shared folder tostore the Security World keys. Alternatively, you may use local copies of the Security World on each node.But if you wish to do this, see Latency issues on page 1 to understand the full consequences.

Please read the following sections to decide the best configuration for your purposes. Exampleconfigurations are shown for use with nShield Solos and nShield Connects. User access to the cluster willtypically be through a virtual server that will have its own name 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, please contact nCipher supporthttps://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. Please see Oracleliterature 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 SecurityWorlds, key protection and failure recovery on page 44

3.5.1 Oracle RAC configuration using nShield SolosA two node Oracle RAC example that is configured to use nShield Solo based HSMs is shown onOracleRAC configuration using nShield Solos on page 34.

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



3.5.1 Oracle RAC configuration using nShield Solos

Figure 3.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 28 (all steps, includingSecurity World creation).

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

3. For the database cluster to function correctly between nodes, the Security World data must be heldin 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 owner=oracle; group=oinstall; permissions=775

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 variable NFAST_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 directory NFAST_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 eachclient. In each case, the Security World must be shown as Initialized and Usable.

If you have not already prepared the protection method you will use, see steps 10 to 12 of theBasicsetting up on page 28.

Please note that in the configuration shown inOracle RAC configuration using nShield Solos on page 34,the shared disk is a single point of failure for both the Oracle database and nCipher Security World data.It is essential that both are backed up on a frequent and regular schedule.

3.5.2 Oracle RAC configuration using nShield ConnectsTwo alternative configurations for use with nShield Connects are shown onOracle RAC configurationusingCommon SecurityWorld on RFS on page 37 andOracle RAC configuration usingCommonSecurityWorld on shared disk on page 41. In both cases a separate server is required to act as host forthe RFS.


3.5.3 Common Security World on RFS

3.5.3 Common Security World on RFSThe RFS shown onOracle RAC configuration usingCommon SecurityWorld on RFS on page 37 isconfigured to hold the Security World data as a shared folder that can be remotely accessed, and is heldin common, by Node 1 and Node 2 of the cluster. The Oracle database is held separately on the clustershared disk. Since the Security World data is held in common on the RFS between both nodes, then thedata on the RFS is always automatically up to date no matter which node is in use, and there are noissues 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 3.2 Oracle RAC configuration using Common Security World on RFS


3.5.3.1 Implementing the Common Security World on RFS configuration

3.5.3.1 Implementing the Common Security World on RFS configurationTo implement this configuration:

1. Install Security World software on the RFS.

The RFS can be either UNIX/LINUX or WINDOWS based. See theUser Guide for yourHSM for 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, seeWhere the remote server is UNIX/LINUX based on page87

b. For a WINDOWS based RFS, seeWhere the remote server is WINDOWS based on page 87

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 8 of the installation instructions in Basic setting up onpage 28. 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 inWhere the local client is UNIX/LINUX based on page 88.

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 using RA forthe ACS cards, you must do so through a registered client). Ensure the Security World is loadedonto each nShield Connect. See the User Guide for your HSM for details.


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 andUsable.



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 andUsable.

l If using nCipher V12 software, on the client run the utility:

nethsmadmin -c -<module number>

The Security World must be shown as Initialized andUsable.

For further details please see the User guide for your HSM.

If you have not already prepared the protection method you will use, see steps 10 through 13 of thesection Basic setting up on page 28.

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.

3.5.4 Common Security World on shared diskThe Security World data shown onOracle RAC configuration usingCommon SecurityWorld on shareddisk on page 41 is contained in a shared folder held in common on the shared disk by Node 1 and Node 2of the cluster. Since the Security World data is held in common between both nodes, then the SecurityWorld data on the shared disk is always automatically up to date no matter which node is in use. In thiscase, the RFS holds a separate copy of the Security World data which must be kept up to date, orsynchronized with the shared disk copy by setting up RFS synchronization facilities. The synchronizationcan be done manually, or on some automatic basis using a suitable shell script.


3.5.4 Common Security World on shared disk

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.



Figure 3.3 Oracle RAC configuration using Common Security World on shared disk


3.5.4.1 Implementing the Common Security World on shared disk configuration

3.5.4.1 Implementing the Common Security World on shared disk configurationTo implement this configuration (seeOracle RAC configuration usingCommon SecurityWorld on shareddisk on page 41):

1. Install Security World software on the RFS.

The RFS can be either UNIX/LINUX or WINDOWS based. See theUser Guide for yourHSM for installation help.

2. On Node 1 and Node 2, complete steps 1 to 8 of the installation instructions in Basic setting up onpage 28. 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 variable NFAST_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 using RA forthe ACS cards, you must do so through a registered client). Ensure the Security World is copied tothe RFS. Ensure the Security World is loaded onto each nShield Connect. See the User Guide foryour HSM for details.


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 andUsable.



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 andUsable.

l If using nCipher V12 software, on the client run the utility:

nethsmadmin -c -<module number>

The Security World must be shown as Initialized andUsable.

For further details please see the User guide for your HSM.

7. On the RFS, set up synchronization as follows (refer to your HSMUser Guide for more detailsabout RFS synchronization):

>>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 12 of theBasicsetting up on page 28.

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.


3.6 Security Worlds, key protection and failure recovery

3.6 Security Worlds, key protection and failure recoveryThis section briefly highlights some considerations when choosing Security World and key protectionoptions for use with the nCipher Security World. It focuses on recovery of Security World authorizationwhere a system has temporarily failed (for instance after a power outage) and is then returned tooperation. This does not apply to other failure recovery functions. These considerations are applicable toSecurity Worlds, key protection and failure recovery for both standalone systems and database clusters.For a fuller explanation of Security Worlds and key protection please refer to the User Guide for yourHSM.

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 using a FIPS 140-2 Level 3 or Common Criteria Security World

l Remote Administration (RA) link, if being used.

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 140-2 Level 3 or Common Criteria Security World authorization is required, this can begranted either by using an OCS card specifically for this purpose, or through an OCS card that is alsoused for credential authorization. A card from the OCS must be always available in a valid HSM cardreader in order to grant reauthorization after a failure, and permit automatic recovery.

If you are using OCS cards through a RA link, then if the link is lost it must be re-established beforerecovery using the OCS cards can begin. There is no automatic mechanism to re-establish the link, whichwould have to be re-established manually, or through some (user defined) script. For this reason we doNOT recommend that RA is used for systems requiring automatic recovery. Systems requiring automaticrecovery using OCS cards, should insert OCS cards directly in the card reader of the HSM.

Never use ACS cards for FIPS 140-2 Level 3 or Common Criteria Security World authorization,as they will not support automatic recovery.

Encryption keys protected by module, softcards or OCS must all be members of the sameSecurity World.

Automatic recovery is dependent on the system returning to operation intact, and whereencrypted database operations cause the required encryption keys to be reloaded onto theHSM. Recovery of interrupted database transactions, or database integrity, is beyond thescope of this document. Test your automatic recovery options work in a safe environmentbefore committing to a production environment.

Using these options, a summary of the authorization recovery behavior of the nCipher Security Worldafter a temporary outage is given in Recovery behavior on page 46.



Corresponding database instances on each node must be protected by the same credential.For OCS credentials, this means using cards from the same 1/N OCS cardset, each card withthe exact same passphrase.


3.6 Security Worlds, key protection and failure recovery

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.

l Do NOT use RA.

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.

l Do NOT use RA.


FIPS level 3

Module

Use OCS for FIPS authorization(only):


l Do NOT use RA.


Use OCS for FIPS authorization (only):


l Do NOT use RA.


Softcard

Use OCS for FIPS authorization(only):


l Do NOT use RA.


Use OCS for FIPS authorization (only):


l Do NOT use RA.


OCS

Use OCS for both credential andFIPS authorization:

l Use 1/N quorum.

l Same passphrase for allcards.


l Do NOT use RA.

Recovers automatically.

Use OCS for both credential and FIPSauthorization:

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


l Do NOT use RA.

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 cardset 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 will not automatically reinstate itself after lossdue to a temporary failure.


4 Configuring and Using nCipher Encryption Facilities

4 Configuring and Using nCipher EncryptionFacilities

4.1 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 using an Oracle database, the nCipher Security World provides and protects the master encryptionkeys (wrapping keys) that are used to wrap Oracle symmetric keys that are in turn used for tablespace ortable column encryption. The Oracle symmetric keys are stored as part of the database itself, althoughprotected 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.

4.2 Storage and distribution of updated master keys

4.2.1 Common storage of master encryption keysWe 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 inOracle RAC configuration using nShield Solos on page 34,Oracle RAC



configuration usingCommon SecurityWorld on RFS on page 37 andOracle RAC configuration usingCommon SecurityWorld on shared disk on page 41of this guide, although it may also apply to non-clusterclients 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 furthershort 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 usinga common store, the master keys are implicitly updated for the use of all clients, and there is no need totrigger 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.

4.2.2 Local storage of master encryption keysIf 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 todistribute keys 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 beincorporated into automated scripts customized for your particular configuration. But elaborating this intoan automated 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 inyour HSM 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 at see https://www.ncipher.com/support.

Local key storage and distribution implies:


https://www.ncipher.com/support

4.2.3 Making a hardserver instance recognize new master keys

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.

4.2.3 Making a hardserver instance recognize newmaster keysIn 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:

CKNFAST_ASSUME_SINGLE_PROCESS=0(see note)

In nCipher Security World version 12.30, this was (incorrectly) inverted, and the variableshould be set to 1.

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.

4.2.4 Other considerationsEven 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 the



Oracle database itself, then it should be possible to do something similar in the application code that isusing the database.

If using the common shared storage, it is expected that any lag in updating the master keys will be shortenough 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.

4.3 Credential and passphrase recommendationsThe protection methods available with the nCipher HSM are, in order of enhanced authentication:

HSM Protection Encryption Description

ModuleEncryption 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 different OCS cardsets where each cardset may protect different encryption 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)


4.3 Credential and passphrase recommendations

Protection Type Credential or <credential>

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

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

Oracle literature gives the ordering <credential-name>|<credential-passphrase>, butwe found the ordering <credential-passphrase>|<credential-name> works.Registered as Oracle Bug 25632335.

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, orcredential-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>, asfollows:

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).

At time of writing, nCipher recommends that a passphrase should consist of at least 14 characters thatinclude alphabetic, numeric and special characters.

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

If you are using a softcard or OCS credential then you must get the <credential-

passphrase> and <credential-name> exactly correct. If you do not, then the credentialstring may be interpreted as a <module-passphrase>. Your encryption keys will then beplaced under module protection rather than the softcard or OCS card protection you intended.

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.

4.4 Configuring Oracle database software to use the nCipherHSMIf you are planning to use multiple databases on the same host, we strongly advise you readUsingmultiple Oracle database instances on the same host on page 76 before continuing.

To proceed, you must have Oracle database software installed with at least one database instance, andalso have the nCipher Security World software with HSM installed in accordance with instructions above.

Please see Keymigration and legacy keys on page 13 before attempting key migration. Some versions ofOracle (11.1g or earlier) may not support migration of some key types from a software wallet to a HSM.Please check the documentation for your Oracle version before attempting key migration.

You can use the following instructions to configure your Oracle database software to function using thenCipher HSM (and Security World software), where:

l (Migration from keystore to HSM).You currently have one or more database instances alreadyusing TDE encryption, each instance with its own software keystore, and you wish to continueusing TDE encryption after migrating the TDE master keys from at least one keystore to thenCipher HSM, or

l (Create keys directly in HSM). You currently have one or more database instances not using TDEencryption, and you wish to start using TDE encryption for at least one database, using the nCipherHSM.

It is assumed you have followed the instructions in the sectionConfiguring andUsing nCipher EncryptionFacilities on page 48, and you know which nCipher HSM protection methods you wish to use, withrequired tokens and credentials ready.

Here is a checklist of things you should have prepared:


4.4 Configuring Oracle database software to use the nCipher HSM

l For your respective protection method, make sure you know the:o <module-passphrase>. Invent one if not already provided. (Please see the sectionCredential and passphrase recommendations on page 51)

o <softcard-name> and associated <softcard-passphrase>

o <OCScard-name> and associated <OCScard-passphrase>

o <wallet-passphrase> if using a software walleto <keystore-passphrase> if using a software keystore.

l If you are using a FIPS 140-2 Level 3 or Common Criteria Security World, and module or softcardprotection, the authorizing OCS card(s) must be inserted into the module card reader(s). If you areusing Remote Administration facilities, then the authorizing OCS cards must be inserted in theTrusted Verification Device (TVD) and registered.

l If you have chosen the OCS card option for key protection, then the OCS card(s) must be insertedinto the module card reader. If you are using Remote Administration facilities, then the OCS cardsmust be inserted in the TVD and registered. If you are using a FIPS 140-2 Level 3 or CommonCriteria Security World, the same OCS cards you are using for key protection will also provideauthorization.

l The target database is open, or the target container (CDB) and all PDBs are open.

l If migrating keys from a software wallet, or keystore, then it must be open. If necessary, pleaserefer toCheckWalletState.sql on page 92.

We do not recommend using Remote Administration if you want automatic recovery in eventof some temporary failure. Please see SecurityWorlds, key protection and failure recovery onpage 44.

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

l May require more than one user with suitable database privileges to make the specific databaseconnections, and run the SQL commands in the sequences as shown. Please respect theconnections shown in order to satisfactorily run SQL on your target. SeeDatabase connections onpage 12. Also see Example SQL scripts on page 90 or adapt examples for your owncircumstances. For real world usage, your system administrator should have sufficient knowledgeto create users and associated privileges according to your organization’s security policies.

l In a particular section of this document, if you are instructed to make a connection as a particularuser, continue with that connection until instructed otherwise.

l Use <credential> to denote the protection method. Choose the protection method you wish touse where <credential> becomes one of:

o Module protection: <module-passphrase>o Softcard protection: <softcard-passphrase|softcard-name>o OCS protection: <OCScard-passphrase|OCScard-name>.



Oracle literature gives the ordering <credential-name>|<credential-passphrase>, butwe found the ordering <credential-passphrase>|<credential-name> works.Registered as Oracle Bug 25632335.

In all cases, after you have completed migrating or creating encryption keys in a HSM, it isrecommended to back up your Security World data, see nCipher SecurityWorld data andback-up on page 79.

In the following SQL, the credential used to open a keystore must match the credential used tocreate an encryption key.

Make sure you use instructions below as appropriate to whether you are using a non-multitenantdatabase (and software wallet), or multitenant database (and software keystore).

4.5 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.



4.6 Migrating from a software wallet to a HSM

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.



--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.

SeeChanging the HSM passphrase or credential on page 70 if you want to change a credential.

4.6 Migrating from a software wallet to a HSMThe 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, please refer tothe sectionMigrating from a software keystore to aHSM on page 57.

We strongly recommend you backup 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 inChanging the HSM passphrase or credential on page70.

In the sqlnet.ora file, if you have previously been using a software wallet, then METHOD should be FILE.Change the METHOD from FILE to HSM, by providing the following lines. If using a RAC cluster, make sureyour 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)))

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


CONNECT sysdba@DB

l 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.7 Migrating from a software keystore to a HSM

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, please contactOracle support 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 are usinga software keystore. If your target database is non-multitenant, please seeMigrating from a softwarewallet to aHSM on page 56.

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 inChanging the HSM passphrase or credentialon page 70.

l You must backup your software keystore before attempting key migration to the HSM.


ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING

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


4.7 Migrating from a software keystore to a HSM

l 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;

l 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;

l Make your keystore into an auto-login keystore. In this case it means that you will be able toopen the keystore with the same commands as for opening the HSM. It does not mean thekeystore will automatically open after a database restart. You may need the keystore to remainopen, even after you 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>";

l 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 followinglines:

ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=HSM) (METHOD_DATA= (DIRECTORY= <path-to-

keystore-folder>/keystore-folder))))


l 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;




4.8 Creating 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, please refer to the sectionCreatingmaster keys directly in aHSM for multitenant database on page 59.

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 inChanging the HSM passphrase or credential on page 70.

l 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))


l 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>";


4.9 Creating master keys directly in a HSM for multitenant databaseThe 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, please refer to the sectionCreatingmaster keys directly in aHSM for non-multitenant database on page 59.

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 nCipher


4.9.1 To create CDB and then all PDB master keys in one operation

key 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 inChanging the HSM passphrase or credential on page 70.

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.

l 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))


4.9.1 To create CDB and then all PDBmaster keys in one operationThis operation appears not to work correctly using module protection. Registered as Oracle Bug25489581. For module protection, we suggest you try the section To create CDBmaster key and a singlePDBmaster key on page 60.

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


ALTER PLUGGABLE DATABASE ALL OPEN;



CONTAINER=ALL;

l 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.9.2 To create CDBmaster key and a single PDBmaster key

4.9.2.1 To create CDB master key:

l 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;

l 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.9.2.2 To create single PDB master key:

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


--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.

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


4.10 Checking the keystore or encryption keysYou can check the state of the software keystore or HSM by following the examples in Example SQLscripts on page 90.

l CheckWalletState.sql

l CheckEncryptionKeys.sql (12c or multitenant only).

Immediately after migration from the keystore to the HSM, you will normally find the software keystorehas been closed and is marked as SECONDARY while the HSM is open and is marked as PRIMARY. (If youhad migrated from the HSM to software keystore, the opposite will be true). The key protector marked asPRIMARY will now take precedence for storing any new keys. You can open the SECONDARY again if youwish to retain access to its contents, but to do so, you must alter its passphrase to be the same as thePRIMARY’s. See sectionMigrating from a software keystore to aHSM on page 57.


4.11 After you have migrated master keys to the HSM (non-multitenant)

4.11 After you have migrated master keys to the HSM (non-multitenant)After you have migrated your encryption keys from the software wallet to the nCipher HSM, the softwarewallet will normally be closed while the HSM will be open. You can check the state of the wallet and HSMby following the CheckWalletState.sql example in Example SQL scripts on page 90. You can openthe software wallet again if you wish to retain access to its contents, but to do so you must alter itspassphrase to be the same as the HSM’s.

Oracle advises you to retain the software wallet in those cases where encrypted data may havepreviously been exported or backed up using keys it contains.

If you wish to be able to continue using a software wallet, you can:

l Update its passphrase to be the same as for the HSM using the orapki utility.

orapki wallet change_pwd -wallet wallet_location [-oldpwd password ] [-newpwd password]

l Convert to an auto-login wallet using the orapki utility. This will automatically open both thesoftware wallet and HSM when the database is restarted. This removes human oversight as towhether the wallet should be opened after a restart.

orapki wallet create -wallet wallet_location -auto_login [-pwd password]

4.12 Automatically open HSM at database restart (multitenant)After a database is restarted, then the HSM will remain closed unless instructed to open. However, thefollowing procedures allow you to set up a HSM to open automatically when the database is restarted.This may be suitable for automatic recovery in case of a temporary database failure, say, due to a powerloss. However, please consider the security implications of allowing the HSM to be reopened withouthuman oversight. Check with your organization’s security policies before implementing this.

In order to open the HSM automatically at a database restart, you must create a software keystore (if onedoes not already exist), and then an auto-open software keystore. In this case the auto-open keystoredoes not hold database encryption keys, but provides the mechanism for the HSM to open. The softwarekeystore will normally appear in the keystore-folder as the file ewallet.p12, and the auto-open keystorewill normally appear in the keystore-folder as the file cwallet.sso.

We suggest that if you wish to use an auto-open keystore, then to avoid potential problems, if possibleyou should set it up before you have created any encryption keys, or encrypted anything in yourdatabase.

4.12.1 Setting up an auto-open keystore before any previous keystore existsDo this if you have not already created any keystore or performed any encryption on your database. Youmust have set up the nCipher pkcs11 library as described in the sectionConfiguring andUsing nCipher



Encryption Facilities on page 48.

1. CONNECT sysdba@CDB<n>

2. In the sqlnet.ora file, provide the following lines.

(Ensure that METHOD = FILE), for example:

ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=FILE) (METHOD_DATA= (DIRECTORY=<path-to-

keystore-folder>/keystore-folder)))

3. Bounce the database, and start a new session, to pick up the changes.

4. Create a software keystore, and then open it:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '<path-to-keystore-folder>keystore-folder'

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

BY "<keystorepassphrase>" CONTAINER=ALL;

5. Incorporate the HSM.

You must include the <hsm-credential> and HSM_PASSWORD in single quotes. It won't work ifyou don't.

ADMINISTER KEY MANAGEMENT ADD SECRET '<hsm-credential>' FOR CLIENT

'HSM_PASSWORD' IDENTIFIED BY "<keystorepassphrase>" WITH BACKUP;

6. Close the keystore:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY

<keystorepassphrase>;

7. Create the auto-open keystore:

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE

'<path-to-keystore-folder>keystore-folder' IDENTIFIED BY

"<keystorepassphrase>";

8. At this point you can check the contents of the folder:

<path-to-keystore-folder>keystore-folder

You should see the files ewallet.p12 and cwallet.sso.


4.12.2 Setting up an auto-open keystore where a software keystore already exists

9. In the sqlnet.ora file, provide the following lines. Ensure that METHOD = HSM), for example:

ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=HSM) (METHOD_DATA= (DIRECTORY=<path-to-

keystore-folder>keystore-folder)))

10. Bounce the database, and start a new session, to pick up the changes. This should also open theHSM automatically.

11. Check the database has opened automatically by running the CheckWalletState.sql script seeCheckWalletState.sql on page 92. You should see the keystore WALLET_TYPE marked asAUTOLOGIN, and the HSM marked as OPEN.

4.12.2 Setting up an auto-open keystore where a software keystore already existsIt is assumed that:

l The multitenant key migration as previously described has been performed

l In the sqlnet.ora file, we start with METHOD = HSM

l The <keystorepassphrase> and <hsm-credential> have already been made the same

l In this case the keystore-folder should already exist. This keystore-folder should contain thefile ewallet.p12.


2. Close the HSM and keystore as:

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

3. Update the sqlnet.ora file so that METHOD = FILE, for example:

ENCRYPTION_WALLET_LOCATION =

(SOURCE = (METHOD = FILE) (METHOD_DATA =

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


5. Incorporate the HSM.











'<path-to-keystore-folder>keystore-folder' IDENTIFIED BY "<keystorepassphrase>";

8. At this point you can check the contents of the folder: <path-to-keystore-folder>keystore-folder You should see the files ewallet.p12 and cwallet.sso.

9. In the sqlnet.ora file, provide the following lines. (Ensure that METHOD = HSM), for example:


(SOURCE = (METHOD = HSM) (METHOD_DATA =



11. Check the database has opened automatically by running the CheckWalletState.sql script, seeCheckWalletState.sql on page 92. You should see the keystore WALLET_TYPE marked asAUTOLOGIN, and the HSM marked as OPEN.

4.12.3 Setting up an auto-open keystore where no software keystore already existsUse this if a HSM keystore already exists but a software keystore does not.


2. Create the keystore-folder, for example: <path-to-keystore-folder>keystore-folder.Make ownership and permissions on the folder as: owner=oracle; group=oinstall;

permissions=755.

3. Perform the following SQL instructions while logged into the target CDB (CDB$ROOT) with suitableuser permissions.

4. Close the HSM as:

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

5. In the sqlnet.ora file, provide the following lines

(Ensure that METHOD = FILE), for example:


4.12.3 Setting up an auto-open keystore where no software keystore already exists


(SOURCE = (METHOD = FILE) (METHOD_DATA =,



7. Create the keystore, and then open it:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/<path-to-keystore-

folder>keystore-folder' IDENTIFIED BY "<keystorepassphrase>";

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY

"<keystorepassphrase>";

8. Incorporate the HSM









'<path-to-keystore-folder>keystore-folder' IDENTIFIED BY "<keystorepassphrase>";

11. At this point you can check the contents of the folder: <path-to-keystore-folder>keystore-folder. You should see the files ewallet.p12 and cwallet.sso.

12. In the sqlnet.ora file, provide the following lines. (Ensure that METHOD = HSM), for example:


(SOURCE = (METHOD = HSM) (METHOD_DATA =





14. Check the database has opened automatically by running the CheckWalletState.sql script, seeCheckWalletState.sql on page 92. You should see the keystore WALLET_TYPE marked asAUTOLOGIN, and the HSM marked as OPEN.

4.13 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.

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.13.1 Rekey when sharing keys between clientsIf 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. However, please read the section Latencyissues on page 48 to understand the 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 been


4.13.2 Rekey for a non-multitenant database

performed, 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.13.2 Rekey for a non-multitenant databaseThe 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.13.3 Rekey for a multitenant database; CDB and all the PDBs in one operationThe following instructions begin by assuming the required CDB is started, and required PDBs and HSM(keystore) to be already open.

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

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

CONTAINER=ALL;

4.13.4 Rekey for a multitenant database; CDB onlyThe following instructions begin by assuming the required CDB is started and HSM (keystore) to bealready open.

CONNECT TESTER@CDB<n> --Assumes CDB is started and HSM already open ADMINISTER KEY

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

4.13.5 Rekey for a multitenant database; single PDB onlyThe following instructions begin by assuming the required CDB is 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 ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<credential>"

WITH BACKUP;

4.13.6 Rekey in a RAC clusterPlease read the section Rekey when sharing keys between clients on page 67 before attempting rekeyin an RAC cluster environment.

Select one node within the cluster on which to perform a rekey. On the selected node, depending onwhether your cluster database is non-multitenant or multitenant, then invoke the required rekeyoperation as described in the sections above.

If you are rekeying within the context of a Security World shared in common across all cluster nodes, asshown inOracle RAC configuration using nShield Solos on page 34,Oracle RAC configuration usingCommon SecurityWorld on RFS on page 37 andOracle RAC configuration usingCommon SecurityWorld on shared disk on page 41 then rekeying on one node of the cluster should implicitly make the newkey(s) available to all other nodes.

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 1 tounderstand the full consequences of these options

If you are using the configuration as shown inOracle RAC configuration usingCommon SecurityWorldon shared disk on page 41, then additionally you must update the encryption keys as stored in the RFS byusing the following command on (any) client node:

>> rfs-sync –commit


5 Changing the HSM passphrase or credential

5 Changing the HSM passphrase or credentialnCipher protection methods with credentials as used by Oracle are as follows:

l Module protection: the credential consists of a passphrase only. (In this case the passphrase is anaccess mechanism for Oracle, and is not used by the HSM)

l Softcard protection: the credential consists of a named softcard token (software based) withassociated passphrase

l OCS protection: the credential consists of a named physical smart card token with associatedpassphrase.

The SQL syntax form for a module protection credential is simply <module-passphrase>. The SQLsyntax form for a softcard or OCS protection credential is <credential-passphrase>|<credential-name>.

In SQL statements, Oracle literature gives the ordering credential-name|credential-

passphrase, but we found the ordering credential-passphrase|credential-name

works as expected. Registered as Oracle Bug 25632335.

If you are using a softcard or OCS credential then you must get the <credential-

passphrase> and <credential-name> exactly correct. If you do not, then the credentialstring may be interpreted as a <module-passphrase>. Your encryption keys will then beplaced under module protection rather than the softcard or OCS card protection you intended.

You can check how keys are protected by using use the nCipher rocs utility with the list keys

command. Use the rocs utility both before and after generating new encryption keys. Comparison of thetwo key lists will show the new entries, and indicate their protection method. You can also use thenCipher cklist utility to achieve the same results, although it is more difficult to identify individual keys.Please see the nCipher User Guide for your HSM for more information about nCipher utilities.

When using softcards or OCS cards, the credential (token and passphrase) must be prepared in thenCipher Security World before attempting to use it with the Oracle database. The database must beprovided with the matching token name and passphrase (through an SQL statement) for the credential itwishes to use. For module protection there is no token, but a passphrase is required for Oracle accesspurposes only. The protection method and associated credential are activated, or bound, to an Oracledatabase at first use by the database instance. Thereafter, the chosen protection method and credentialwill be used to protect any encryption keys created and used by the database instance. You will not beable to create or use encryption keys protected by any other protection method and credential for aparticular database instance, unless you actively alter them using the correct authorization mechanisms.

If you wish 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.

Note: If using a FIPS 140-2 Level 3 or Common Criteria Security World then:



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

l To alter the passphrase of an OCS card (or create a new OCS card) you will require authorizationusing ACS cards.

To alter the protection method or credential, there are three options:

1. Continue using the same protection method and token, but change the associatedpassphrase. (For module protection there isn’t a token, but you can change the passphrase). Inthis case, after the passphrase is altered, TDE will continue working using the new passphrase, asthe TDE encryption keys being protected will remain the same.

2. Continue using the same protection method, but change the token and passphrase.

You then have the further options of:a. Not transferring encryption keys from the previous token to the new token, in which case

you can no longer continue using TDE as protected by the previous token’s keys. You willonly be able to use TDE encryption keys shielded under the newly activated credential.

b. Transferring encryption keys from the previous token to the new token, in which case youcan continue using TDE as protected by the previous token’s keys. However, you may onlytransfer keys between different softcards, or else different OCS cards. You cannot transferkeys between softcards and OCS cards.

3. Change the protection method and associated credential with passphrase. In this case youwill not be able to transfer any encryption keys between the different protection methods. You willonly be able to use TDE encryption keys shielded under the newly activated protection method andcredential.

5.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.


5.2 Change token with associated passphrase but keep same protection method

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 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;

5.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




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. Please see the section nCipher SecurityWorld data and back-up on page 79.

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-


5.3 Change protection methodTo change the protection method, complete the following instructions:


CONNECT TESTER@DB




l Multitenant only:


5.3 Change protection method



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-



6 Using multiple Oracle database instances on the same host

6 Using multiple Oracle database instances onthe same hostThe same host server can run more than one independent Oracle database instance at the same time,and multitenant and non-multitenant databases can be mixed on the same host if you wish. However,using multiple instances on the same host may not be an efficient use of computing resources, and addsto complexity.

Where possible, it is often more efficient to incorporate all your database requirements into onedatabase. In any case, use of PDBs within a multitenant database effectively allows you to have multipledatabases while using only one (CDB) database instance to run them all.

For simplicity and efficiency, we strongly recommend you run only one Oracle database instance per host(or client) server. That is, one non-multitenant database (non-CDB) instance per host server, or onemultitenant (CDB) instance per host server.

However, if you do need to run more than one instance on the same host, please read the following.

nCipher Security World software can run only one hardserver (Security World server instance) on thesame server host at the same time. This means that if you wish to encrypt more than one databaseinstance on the same host using the nCipher HSM, you must share the same Security World and HSMbetween all the databases that you wish to encrypt. Nevertheless, even though each database instancemust share the same Security World, it is possible to use different nCipher credentials and protectionmethods for the encryption keys used by each database. By this means the encryption keys for eachdatabase instance can remain inaccessible to any database other than the owning database, eventhough sharing the same Security World.

However, if using module protection, a passphrase is required for the Oracle database accessmechanisms only. The Oracle module protection passphrase does not have a reference (or counterpart)in the nCipher HSM. This means a user who is able to access keys directly in the HSM will be able toaccess module protected keys for any database without requiring the (Oracle) passphrase. This does notapply for softcard or OCS protection.

All database instances will share the same Security World, then if the Security World is FIPS 140-2 Level 3or Common Criteria, all the database instances can share the same OCS card(s) for authorization. Thiswill be required if using FIPS140-2 Level 3 or Common Criteria, even if using module or softcardprotection methods.

If you are using (1/N) OCS cards for key protection, then the OCS cardset must be loaded on the HSM inorder to assign the keys to the OCS cardset, or later authorize the use of those keys. If you use a non-persistent OCS cardset, then an OCS card must be present in the HSM card reader when you wish toassign or authorize the use of the keys it is protecting. When authorizing use of the keys, this could beproblematic if you wish to use different OCS non-persistent cardsets to protect different keys at the sametime for different database instances. This is because they would have to physically share the same cardreader slot. You can overcome this by using and loading different persistent OCS cardsets instead, orelse using nCipher V12 software with Remote Administration (RA) facilities to create multiple virtual cardreader slots. However, if there is system failure, caused by (say) a power loss, the authorization of



persistent OCS cards, or RA connections, will be lost. Recovery will necessitate restoration of thepersistent OCS card authorization, and/or RA connections.

If you are running multiple database instances on the same host and you are using TDE encryption withan Oracle software keystore, the recommended mode of operation is to use a separate softwarekeystore for each database to protect its encryption keys. If you then wish to migrate those encryptionkeys to a nCipher HSM, you will have to migrate the keys from each separate keystore in turn.

Multiple database instances on the same host may share common base software and TNS_ADMIN

environment variable, and therefore will share the same Oracle sqlnet.ora, listener.ora andtnsnames.ora files. (May not be applicable to Oracle RAC clusters). The sqlnet.ora file tells theconfiguration whether to use a software keystore, or HSM, or both if migrating keys. You must edit thesqlnet.ora file to meet your current requirements, but changes to this shared file will affect all databaseinstances, even if you only want to affect one of them. In this case, if you decide to migrate the encryptionkeys from one database software keystore to a HSM, then all other databases that share the samesqlnet.ora file will have to follow in turn in migrating their master keys to the HSM.

For a temporary period during the key migration operations, this may result in one or more databaseinstances with master keys protected by the HSM, whilst other databases remain with master keysprotected by a software keystore. During this period, those databases with keys protected by the HSMshould continue to function as normal using TDE. However, for the key migration period, you should notattempt any rekey of those databases whose keys have not yet been migrated to the HSM. Thosedatabases that remain with keys protected by software keystores may continue to function using TDE,provided they continue to use only existing keys.

If you wish to avoid problems that may be caused by multiple database instances sharing the samesqlnet.ora file, it is possible to set the Oracle TNS_ADMIN as a local environment variable to point to adifferent directory for each database instance. Each database instance can then hold its own copy of theOracle sqlnet.ora, listener.ora and tnsnames.ora files. This avoids interference between thedatabase instances, allowing some database instances to use a HSM, while others may continue to use asoftware keystore. In this case, the mixed use of HSM and software keystores on the same shared hostcan continue indefinitely. You may then migrate the keys from each software keystore to the HSM at yourleisure.



Here is a procedure that allows you to provide a different TNS_ADMIN environment for multiple databaseinstances. This may not apply for some cluster configurations. Starting with the case where all instancesshare the same common directory, that is:

TNS_ADMIN =$ORACLE_HOME/network/admin, that contains shared Oracle sqlnet.ora,listener.ora and tnsnames.ora files.

1. Create a new (TNS_ADMIN) folder for each database instance based on its ORACLE_SID value, forexample:

UNIX:

$ORACLE_BASE/$ORACLE_SID/<tnsadmin>

WINDOWS:

%ORACLE_BASE%\%ORACLE_SID%\<tnsadmin>

2. Copy the sqlnet.ora, listener.ora and tnsnames.ora files from the common TNS_ADMIN

folder to each new TNS_ADMIN folder you have created for each database instance.

3. Within the local environment for each database instance, set the value of the TNS_ADMIN variable:

UNIX:

TNS_ADMIN=$ORACLE_BASE/$ORACLE_SID/<tnsadmin>

WINDOWS:

TNS_ADMIN=%ORACLE_BASE%\%ORACLE_SID%\<tnsadmin>

4. Bounce the database instance.

For multitenant databases (only), there is provision to merge several keystores into one. For more detailson merging of keystores, please consult the Oracle literature. By merging into a single keystore, you maysuppose that you may save time from otherwise having to migrate the keys from several keystores to theHSM. But the time saved may not be significant.


7 nCipher Security World data and back-up

7 nCipher Security World data and back-upOperational data used by the Security World software is all the data held in the directory(s) under the KeyManagement Data directory, or NFAST_KMDATA, (typically) on a local host at:

l UNIX: /opt/nfast/kmdata

l WINDOWS: C:\ProgramData\nCipher\Key Management Data

This includes the following subdirectories:

l config

l features

l hardserver.d

l local

l tmp

l warrants (if using Security World v12 or later).

Of the above folders, local is the most important.

The local sub-directory is also called a Security World folder and holds the Security World data. Thisincludes the cryptographic data files essential for the operation of the nCipher Security World.Cryptographic files in the local sub-directory may update or change regularly and cannot be replaced iflost. These files should be the focus of back-up.

The sub-directories other than local contain Security World configuration data. Once a configuration isestablished it is unlikely to change frequently. In any case, it is possible for the configuration data to beregenerated or replaced. Its loss may impede rapid restoration of a failed system, but the system shouldnot be irrecoverable. Configuration files are not inherently encrypted. Information contained in them maygive an adversary some knowledge of your configuration, but will not directly compromise the security ofyour cryptographic material. The configuration files must remain unencrypted for the nCipher SecurityWorld software to work. If you wish to protect the configuration files from unauthorized snooping, youmust do this through access control mechanisms, but allowing access the nCipher Security Worldsoftware.

Hence, a practical back-up strategy is to save an initial copy of the configuration sub-directories, andthereafter only update this back-up if the configuration is known to have changed. The configuration fileback-up can be encrypted for extra security if you wish.

All files that are held in the local folder are encrypted. If lost or stolen, they will be useless to anyonewho does not possess the correct authorizing mechanisms to use them, such as ACS cards, OCS cards,HSM, associated passwords and nCipher Security World software. Therefore back-up of the local datamay simply consist of making a copy of it, and placing the copy in a safe location. No further encryption isnecessary. The safe location should be physically separate from any location holding a copy of theassociated database.

Further information about backing up the Security World can be found in the User Guide for your nShieldHSM.



The contents of the NFAST_KMDATA folder are transferable between UNIX and WINDOWShosts. This includes ACS, OCS and softcards. In other words, a Security World created on aUNIX host can be directly copied and used by a WINDOWS host, after authorized loading ontoa HSM, and vice-versa.

7.1 The local directoryThe local sub-directory, or Security World folder, contains the files needed to perform the cryptographicfunctions of the Security World. When performing a back-up of this data, you must include ALL the data inthe local sub-directory, as described in the previous section.

Your Security World data is valuable. Access to the Security World folder should only be allowed forauthorized users. Furthermore, it is possible to control usage permissions for individual cryptographicfiles to particular users only, in order to fine-grain authorized access to cryptographic operations wherethose files are used. However, check with your organisation’s security policies before you do this.

The local folder contains the following cryptographic files. If you need to set permissions to controlaccess to individual cryptographic files, then you will need to know something about those files, asfollows.

The following file is the minimum necessary data to initiate a functional Security World:

l world – holds information relating to the Security World’s type, its other characteristics, and ACScards.

The world file must be generated by the Security World software and is loaded onto the target HSM(s)upon creation. Otherwise, a pre-existing world file must be loaded onto the target HSM(s) using its ACScard(s). Please refer to the User Guide for your HSM for more information about creating or loading aSecurity World.

Unless the world file is loaded onto a usable HSM, no other cryptographic files associated with it in thelocal folder will function.

Other files in the local directory that may be associated with the world file are as follows. None of thethese files can be created unless a world file already exists, and once they exist will only work with theworld file they were created under.

l cards_<hash> - holds information about an OCS cardset where <hash> is a number unique to thecardset. The same <hash> will be used by all individual card files that are members of the samecardset.

l card_<hash>_<n> - holds information about an individual OCS card where <hash> is the OCScardset hash, and <n> is the individual card’s creation sequence number.

l softcard_<hash> - holds information about a softcard where <hash> is a number unique to thesoftcard.

l key_pkcs11_<hash> – holds information about a pkcs11 encryption key where <hash> is anumber unique to the key. The nCipher library API only works with pkcs11 keys.


7.2 Disaster recovery preparation

If using module protection, the passphrase used is an Oracle access mechanism only. It is notused by the nCipher Security World and is not stored by it. However, you should find a key_

pkcs11_<hash> file that relates to the protecting key for the module protection.

Please refer to theUser Guide for your HSM for more information about creating OCS or softcards.

All the above files are inherently encrypted and are useless to anyone who does not possess the correctauthorizing mechanisms. Be very careful about deleting any of the above files from the local folder.Unless you have a back-up, any such file that is deleted from the local folder is lost for good.

The local subdirectory may also contain the following file(s), but which may not be needed if a differenthardware configuration is used, and also should not be difficult to replace.

l module_<ESN> – where <ESN> is a module’s Electronic Serial Number. Holds information about aHSM that is configured to use the Security World.

Together, the world file and the (above) files created under it comprise a Security World’s cryptographicdata. These files should always be kept exclusively together in their owning Security World folder. Thecontents of the Security World folder distinguish between different Security Worlds. Files from differentSecurity World folders should NEVER be mixed in the same folder and will not work with the wrong worldfile in any case (although keys can be imported using correct procedures).

IMPORTANT: Always make sure you have an up to date back-up of your Security World data thatincludes all files in the local folder.

You can switch between different existing Security Worlds while retaining the same systemconfiguration by renaming the desired Security World folder to local. You must then load theSecurity World by using its associated ACS cards.

7.2 Disaster recovery preparationIt should be part of your corporate disaster recovery policy to perform regular back-ups of both yourdatabase and associated Security World such that the back-ups remain up to date and synchronized witheach other.

The back-up strategies you employ and how you implement them will depend on your particularcorporate policies and requirements, and the specifics of the type of configuration you are using. Thisguide cannot cover all the potential options and complexities, and will only provide broad advice on back-up and restoration using the supported forms of database encryption. Whichever back-up or restorationoption you use, make sure you have safely tested it before putting it into practice.

When a Security World is created, an ACS cardset (one only) is created at the same time. You shouldchoose a quorum of ACS cards in accordance with your corporate security policy. The total number ofcards in the ACS cardset should include surplus cards in case of failure or loss of an ACS card. The ACScards authorize loading of the Security World, and some management operations on its OCS cardsetsand softcards (please see the User Guide for your HSM). You should always store your ACS cards in asecure location. Normally, you should not need to use the ACS cardset for everyday use with a nCipher



Security World. However, you may need to use it if you are restoring a Security World that was previouslyarchived and must be reloaded onto an nShield HSM.

An OCS cardset is used to authorize use of encryption keys that are assigned to and protected by thatOCS cardset. Softcards perform a similar function. There can be more than one OCS cardset and/orsoftcard. However, a softcard exists as a single entity and has only passphrase protection. Generally, anOCS cardset is considered more secure than a softcard because it can be created with a quorum ofmultiple cards, physical presence of the cards is required, and each card can be supplied with its ownpassphrase. However, these advantages may be somewhat constrained when used with the Oraclecredential, which entails a 1/N quorum and identical passphrase for every card in the OCS cardset for thecards to be used interchangeably with the same credential.

The total number of cards in the OCS cardset should include surplus cards in case of failure or loss of anOCS card. Some of the cards should always be kept in a secure location, and access to OCS cards ineveryday use should be restricted to authorized persons.

The presence of a protecting OCS card, or softcard, will be required when performing back-up orrestoration operations for a TDE encrypted database.

Master encryption keys, OCS card data and softcard data that are protected by the Security World arestored in its local folder (please see section The local directory on page 80). This applies to the TDEmaster keys that are used to protect the tablespace or column encryption keys, but does not apply to theactual tablespace or column encryption keys which are stored as an integral part of the related database.

The Security World will hold the encryption keys for ALL current databases it is being employed with. Thatmay include encryption keys for databases you are not specifically backing up. You may find itconvenient that you need only one Security World back-up to cover several databases. Otherwise youwill need to pursue a policy of one Security World for one database, but in this case you can run only oneSecurity World per host server.

7.3 Backing upBefore backing up a database and corresponding Security World, make sure you are using versions ofboth that are synchronized to each other. That is, the Security World holds all the up to date and correctencryption keys that are being used by the matching database.

When performing back-ups, it is advised to back-up the database first, before backing up the SecurityWorld.

When backing up a TDE encrypted database, you must have the TDE credential (including OCS card orsoftcard) and database master encryption key present.

With TDE encryption, the table and/or tablespace encryption keys are an integral part of the relateddatabase and are stored within the back-up, and not in the Security World. These keys are protected bythe TDE master key(s) that are held in the Security World.

If using a cluster which holds the local folder on a shared disk, the exact same database and masterencryption key(s) are being used irrespective of the currently active node. Hence it should not matterwhich node is currently active when a back-up is made.


7.3 Backing up

You may back-up the database in a similar manner to an unencrypted database. If you are backing up aTDE encrypted database, it will be backed up while remaining in its encrypted form, which isadvantageous from a security point of view. After you have backed up the database, you can thenproceed to back-up the associated Security World folder.

Refer to section The local directory on page 80 for information about locating the Security World data,and the files you need to back-up.

The Security World data is inherently encrypted and does not require any further encryption operation toprotect it. It can only be used by someone who has access to a quorum of the correct ACS cards, OCScards, softcards, associated passphrases, an nShield HSM and nCipher Security World Software.

Therefore back-up should simply consist of making a copy of the Security World files and placing thecopy in a safe location. You should not store back-up copies of the Security World in the same physicallocation as its corresponding database. You must keep a record of which database and which SecurityWorld backups correspond to each other, and where they are located.

You should also securely store and keep a record of ACS and OCS cards associated with each SecurityWorld, as necessary to restore the keys used by a database. If you are using many ACS or OCS cards,you may consider securely documenting the associated passwords. Also, the more encryption keys inyour Security World, the more necessary it becomes to record which keys are used to encrypt whichdata.

If you are backing up as part of a long term archive, and you are storing ACS and OCS cards for morethan one Security World, make sure you have some way of clearly identifying which cards belong towhich Security World.


8 Troubleshooting

8 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 configuration file, no resultantchange in the database behavior is observed.


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

ORA-28367: wallet does

not exist

Check you have correctly installed and configured the nCipher pkcs11library. See section Basic setting up on page 28

Check your sqlnet.ora file contains the correct location, is syntacticallycorrect, and has the required permissions.


Try bouncing the database.

Try restarting the nCipher hardserver.

ORA-28367: cannot find

PKCS11 library

In path variables, do not confuse \ separators for Windows, and /separators for UNIX. Ensure that oracle:oinstall is the owner:group of theopt/oracle/extapi/… directory, with read and write access.

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

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

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


8 Troubleshooting


Try experimenting with the library file permissions.


Re-copy the libcknfast[-64].so library file to/opt/oracle/extapi/…and ensure it has correct ownership andpermissions (oracle:oinstall :755).

ORA-28353: failed to

open wallet

Check 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 correct and are separated by a | or :. If you have migrated from an Oraclewallet to a HSM wallet, you must update the passphrase. See Installationand configuration on page 22.

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. See KnownOracle bugsand patches on page 10.

Ensure that if a FIPS 140-2 Level 3 or Common Criteria Security World isin use, an OCS card is inserted in the HSM slot.

Check you are using the correct passphrase/credential to access theHSM.

Check you have appropriate privileges to use encryption keys.

Check you have appropriate ownership/permissions to access theSecurity World (local) folder. Typically, the following works:

Owner:nfast;Group:nfast;permissions 2777

If using an nShield Connect, use its front panel to check the SecurityWorld 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. SeeKnownOracle bugs and patches on page 10.

When using persistent OCScards, the persistent authorization is lost.

This may be caused by Oracle bug 23528412: Please contact Oraclesupport in order to obtain a patch for this bug. See KnownOracle bugsand patches on page 10.

ORA-00600: internal

error code, arguments:

[kzthsmgmk: C_

Ensure that you have added user oracle to group nfast. In some casesyou may have to re-login with the oracle user for this to take effect.Ensure that if a FIPS 140-2 Level 3 or Common Criteria Security World is


8 Troubleshooting


GenerateKey], [6], [],

[], [], [], [], []in use, an OCS card is inserted in the HSM slot.

ORA-00600: internal

error code, arguments:

[ksqgel:null_parent],

[], [],[], [], [], [],

[]

Sometimes occurs using encrypted tablespaces. This may be caused byOracle bug 21080143: Please contact Oracle support in order to obtain apatch for this bug. See KnownOracle bugs and patches on page 10.

ORA-28374: Typed

master key 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

service name is

incorrectly specified

Check you have correctly set the value for ORACLE_SID in your local environment.


Appendix A Setting up a Remote Shared Folder

Appendix A 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.

A.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. Provide appropriate folder permissions.

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,for example:

[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

A.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. Provide appropriate folder permissions.


Appendix A Setting up a Remote Shared Folder

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.

This can be Everyone, but check with your organizations security policies before using this.

A.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 eithera UNIX/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:


A.3 Where the local client is UNIX/LINUX based

>>/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 B Example SQL scripts

Appendix B Example SQL scriptsIf using sqlplus, use SET SERVEROUTPUT ON; to see tabular output in a session. You may also wish toinclude formatting to make tables more easily readable.

If using sqldeveloper, replace SET SERVEROUTPUT ON; with SET sqlformat ansiconsole; to providemore easily readable tabular output in a session.

B.1 CreateC##Tester.sql

--Creates the C##TESTER. For multitenant database use only. --A common user name must

be prefixed with 'C##' --The C##TESTER is a 'common' user which should be able to

access the CDB and all PDBs. SET SERVEROUTPUT ON; --You must be connected to CDB$ROOT

to run this. --Run as 'sysdba' ALTER SESSION SET CONTAINER = CDB$ROOT; SHOW con_name;

ALTER PLUGGABLE DATABASE ALL OPEN; CREATE USER C##TESTER IDENTIFIED BY Tester --This is

the 'TESTER' password. Keep easily memorable for testing. ACCOUNT UNLOCK CONTAINER =

ALL; --Note, this does not give you access to all PDBs. --This line allows CDB/PDB

access ALTER USER C##TESTER SET container_data=ALL CONTAINER = CURRENT; --Give

C##TESTER privileges GRANT SYSKM TO C##TESTER CONTAINER = ALL; GRANT ADMINISTER KEY

MANAGEMENT TO C##TESTER CONTAINER = ALL; GRANT SET CONTAINER TO C##TESTER CONTAINER =

ALL; GRANT CREATE CREDENTIAL TO C##TESTER CONTAINER = ALL; GRANT CREATE SESSION, ALTER

SESSION TO C##TESTER CONTAINER = ALL; GRANT CONNECT TO C##TESTER CONTAINER = ALL; GRANT

DBA TO C##TESTER CONTAINER = ALL; GRANT CREATE TABLESPACE, ALTER TABLESPACE, DROP

TABLESPACE, UNLIMITED TABLESPACE TO C##TESTER CONTAINER = ALL; GRANT CREATE ANY TABLE,

ALTER ANY TABLE, BACKUP ANY TABLE, DELETE ANY TABLE, DROP ANY TABLE, INSERT ANY TABLE,

SELECT ANY TABLE, UPDATE ANY TABLE TO C##TESTER CONTAINER = ALL; GRANT EXECUTE ANY

PROCEDURE TO C##TESTER CONTAINER = ALL; GRANT ALTER ANY PROCEDURE TO C##TESTER

CONTAINER = ALL; GRANT CREATE DATABASE LINK, CREATE PUBLIC DATABASE LINK TO C##TESTER

CONTAINER = ALL; GRANT CREATE JOB, CREATE EXTERNAL JOB TO C##TESTER CONTAINER = ALL;

COMMIT; SET sqlformat ansiconsole; --Check that the 'C##TESTER' was created SELECT *

FROM ALL_USERS WHERE username = 'C##TESTER'; --Use upper case 'C##TESTER'

B.2 CreateTester.sql

--Can be used to create a user for non-multitenant database. --Can be used to create a

PDB<k> user for multitenant database

--You must be sysdba or have correct administrator privileges to run this.

--Ensure you connect to the correct database, or CBD<n>PDB<k>, to create <TESTER-NAME>

--Suggest <TESTER-NAME> is ‘TESTER’ for non-multitenant database

--Suggest <TESTER-NAME> is ‘PDB<k>TESTER’ as local user for PDB<k> database

CREATE USER <TESTER-NAME>

IDENTIFIED BY Tester --Passphrase. Keep easily memorable for testing.


Appendix B Example SQL scripts

ACCOUNT UNLOCK;

SET SERVEROUTPUT ON;

--Check that the '<TESTER-NAME>' was created

SELECT * FROM ALL_USERS WHERE username = '<TESTER-NAME>'; --Use upper case

B.3 GrantTesterPrivileges.sql

--Not applicable to C##TESTER --Grants privileges to <TESTER-NAME>. Replace with existing

user name.

--You must be sysdba or have correct administrator privileges to run this.

--For test purposes here, privileges are generous.

--For real system, your administrator should grant allowed privileges.

GRANT ADMINISTER KEY MANAGEMENT; --For multitenant database only

GRANT SET CONTAINER TO <TESTER-NAME>; --For multitenant database only

GRANT SYSKM TO <TESTER-NAME>; --For multitenant database only

GRANT CREATE CREDENTIAL TO <TESTER-NAME>; --For multitenant database only ... .. GRANT

CREATE CREDENTIAL TO <TESTER-NAME>; --For multitenant database only GRANT ALTER SYSTEM TO

<TESTER-NAME>; --Non-multitenant must have this to create master keys Etc... ..

GRANT CREATE SESSION, ALTER SESSION TO <TESTER-NAME>;

GRANT CONNECT TO <TESTER-NAME>;

GRANT DBA TO <TESTER-NAME>;

GRANT CREATE TABLESPACE, ALTER TABLESPACE, DROP TABLESPACE, MANAGE

TABLESPACE, UNLIMITED TABLESPACE TO <TESTER-NAME>;

GRANT CREATE ANY TABLE, ALTER ANY TABLE, BACKUP ANY TABLE, DELETE ANY

TABLE, DROP ANY TABLE, INSERT ANY TABLE, SELECT ANY TABLE, UPDATE ANY TABLE

TO <TESTER-NAME>;

GRANT EXECUTE ANY PROCEDURE TO <TESTER-NAME>;

GRANT ALTER ANY PROCEDURE TO <TESTER-NAME>;

GRANT CREATE DATABASE LINK, CREATE PUBLIC DATABASE LINK TO <TESTER-NAME>;

GRANT CREATE JOB, CREATE EXTERNAL JOB TO <TESTER-NAME>;

COMMIT;

B.4 CheckTesterPrivileges.sql

-- Allows you to verify the privileges granted to <TESTER-NAME>.

-- Replace with existing user name.



B.5 CheckEncryptionKeys.sql

select * from DBA_ROLE_PRIVS where Grantee ='<TESTER-NAME>';

select * from DBA_SYS_PRIVS where Grantee = '<TESTER-NAME>';

B.5 CheckEncryptionKeys.sql

-- Checks the current encryption keys (12c only)

-- Make sure you are connected to correct database

-- and have appropriate privileges.


SET lines 256

SET trimout on

SET tab off

COLUMN KEY_ID FORMAT a35;

COLUMN ACTIVATION_TIME FORMAT a35;

COLUMN KEYSTORE_TYPE FORMAT a8;

COLUMN KEY_USE FORMAT a8;

COLUMN CREATOR FORMAT a15;

COLUMN USER FORMAT a15;

COLUMN ACTIVATING_DBNAME FORMAT a20;

SELECT KEY_ID, ACTIVATION_TIME, KEYSTORE_TYPE, KEY_USE, CREATOR, USER,

ACTIVATING_DBNAME FROM v$encryption_keys;

B.6 CheckWalletState.sql

--Allows you inspect the encryption wallet state.

-- Make sure you are connected to correct database

-- and have appropriate privileges.


SET lines 256

SET trimout on

SET tab off

SELECT * FROM sys.v_$encryption_wallet;


Appendix C Ghost data

Appendix C Ghost dataIf you create unencrypted table(s) that contains columns of strings within an unencrypted tablespace, itmay be possible to read the strings at the disk storage location using a text editor, if the strings remain inhuman readable format. Even if you later encrypt those columns with a table key, ghost images of theoriginal human readable strings may persist for a while in the database file that holds the table. Theseghost images should eventually be overwritten by resource maintenance activities. If ghost images areunacceptable after (you think) you’ve safely encrypted sensitive data, you can avoid ghost imagesaltogether by using an encrypted tablespace in the first place to store the table(s).

You can use tablespace and column encryption together.


D Glossary

D GlossaryAdministrator Card Set (ACS)

Part of the Security World architecture, an Administrator Card Set (ACS) is a set of smart cards used tocontrol access to Security World configuration, as well as recovery and replacement operations.

Container Database

See "Multitenant" on the facing page

Close database

See "Open/Close database" on page 96.

Common Criteria (CC)

An International Standard for computer security. For more information, please seehttps://www.commoncriteriaportal.org/

Connection

A communications channel between a client and server, or (Oracle) database and a user. Onceestablished, a connection may host zero, one, or many sessions.

See "Session" on page 97

Credential

A passphrase, or combined passphrase and associated named token, used by the Oracle database as areference (or counterpart) to the nCipher protection method that is required to be used.

Federal Information Processing Standards (FIPS)

The Federal Information Processing Standards (FIPS) were developed by the United States federalgovernment for use by non-military government agencies and government contractors. FIPS 140 is aseries of publications intended to coordinate the requirements and standards for cryptographic securitymodules, including both their hardware and software components.

All Security Worlds are compliant with FIPS 140-2. By default, Security Worlds are created to comply withFIPS 140-2 at level 2, but those customers who have a regulatory requirement for compliance withFIPS 140-2 at level 3 can also choose to create a Security World that meets those requirements.

For more details about FIPS 140-2, see http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf.

Hardserver

The server instance for the nCipher HSM. Runs as a daemon.

Hardware Security Module (HSM)

A Hardware Security Module (commonly referred to as an HSM) is a hardware device used to holdcryptographic keys and software securely.

ID

IDentity


https://www.commoncriteriaportal.org/

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

Key (encryption)

Key (encryption)

A random string of bits used to transform (or encrypt) plaintext data into an unreadable cipher in order toprotect the data from eavesdropping. Usually, the longer the number of key bits, the more secure thecipher from unwanted decryption. Keys can be symmetric or asymmetric. The same symmetric key isused to both encrypt and decrypt the cipher in a reversible process. An asymmetric key has to begenerated using specific algorithms and has two parts, public and private. There is no easy way to deriveone part from the other. As its name suggests, the public part can be publicly known and is used toencrypt data. The private part should be kept secret and secure, and known only by those parties thatwish to decrypt the data. Although an asymmetric key has two parts, it is usually referred to as a singlekey, as one part is useless without the other.

Key (wrapping)

Normally used in the context of an encryption key that is used to encrypt, or wrap, another encryption keyin order to protect it. The same wrapping key is also used to unwrap the protected key when it is neededfor use. All keys and cryptographic data that are held in a nCipher Security World data folder are wrapped

and cannot be decrypted without the appropriate module key that is (only) held in the HSM.

Key migration

The transfer of encryption responsibilities from an Oracle software keystore to a HSM, or vice-versa. Theencryption keys themselves are not migrated. New master key(s) are created in the software keystore orHSM, and subsidiary keys are re-encrypted using the new master key.

Key protector

The software keystore or HSM that is currently responsible for protecting the master keys.

Keystore (software)

(Oracle version 12c terminology). An encrypted data file that holds master encryption keys for an Oracledatabase.

Legacy key

A previous master key that has been replaced by a new master key. You should retain your legacy keysin case you have backups that require them.

Module

See "Hardware Security Module (HSM)" on the previous page

Module key

A module key is a cryptographic key generated by each nShield module at the time of initialization andstored within the module. It is used to wrap key blobs and key fragments for tokens. Authorization for itsuse is controlled by the ACS cardset. Module keys can be shared across several modules to create alarger Security World.

See also: "Security World" on page 97, "Hardware Security Module (HSM)" on the previous page.

Multitenant

An (Oracle) container database that contains between zero and 253 ‘pluggable’ databases (see PDBs).A container (see CDB) holds resources in common for all pluggable databases it contains, butcorresponds to one database instance when running. Holding system resources in common for many


D Glossary

PDBs is more efficient than conventional databases where resources must be replicated for eachdatabase, and is also easier to maintain and update.

For Oracle, this will apply to12c and later versions.

Non-container

See "Non-multitenant" below

Non-multitenant

A conventional database with its own allocated resources, and that will correspond to one databaseinstance when running.

For Oracle, this will apply to pre-12c versions

Operator Card Set (OCS)

Part of the Security World architecture, an Operator Card Set (OCS) is a set of smart cards containingshares of the logical tokens that is used to control access to application keys within a Security World.OCSs are protected using the Security World key, and therefore they cannot be used outside the SecurityWorld.

See also: "Security World" on the facing page, "Administrator Card Set (ACS)" on page 94.

Open/Close database

Oracle has a control system that gates access to a keystore or HSM. If a keystore or HSM is ‘open’, thenyou can access its contents. If a keystore or HSM is ‘closed’, then you cannot access its contents.

Plaintext

Data or object information that is unencrypted.

Pluggable Database (PDB)

Behaves effectively like an independent conventional database, although it is held in a containerdatabase. Each PDB holds database information private to that PDB. A PDB does not have its owndatabase instance, but you can connect to it if its owning container database instance is running. A PDBcan be ‘unplugged’ from one container and ‘plugged’ into another container.

For Oracle, this will apply to12c and later versions.

Remote Administration (RA)

Feature introduced in nCipher v12 and later Security World software (only). Permits remote use of ACS orOCS cards on a remote host using a TVD, and without use of an associated Security World.

Remote File System (RFS)

The RFS holds master copies of Security World (local) files that the nShield Connect(s) needs. It can beany host server that is accessible on the network. The RFS and clients can be the same machine.However, if the RFS and clients are separate machines, it should not matter if the RFS is UNIX/LINUX orWINDOWS based, provided it holds the same Security World as the clients. A client may have its owncopy of the Security World, and may independently update encryption keys or files within its own copy. Inthis case, you must set up rfs-sync facilities to permit the RFS Security World to update andsynchronize with the client copy, or else for the client copy to synchronize with the RFS copy.


Security World

Security World

The Security World technology provides an infrastructure for secure lifecycle management of keys. ASecurity World consists of at least one HSM, some cryptographic key and certificate data encrypted by aSecurity World key and stored on at least one host computer, a set of Administrator Cards used to controlaccess to Security World configuration, recovery and replacement operations, and optionally one or moresets of Operator Cards, and/or softcards used to control access to application keys.

See also "Administrator Card Set (ACS)" on page 94, "Operator Card Set (OCS)" on the previous pageand "Softcard" below.

Security World data

This is data held in the local folder under the Security World Key Management Data directory (NFAST_KMDATA/local). This folder holds the cryptographic data files essential for the operation of the nCipherSecurity World. The files are visible to anyone with authorized access to the folder. However, the files areinherently encrypted, and are useless to anyone without a nCipher HSM, Security World software, andthe correct authorizing mechanisms to load the data onto the HSM and use it. If lost, the contents of thisfolder are irreplaceable. The folder must always be backed up frequently and regularly. Contents of theNFAST_KMDATA folder are transferable between UNIX and WINDOWS hosts. This includes ACS, OCSand softcards. In other words, a Security World created on a UNIX host can be directly copied and usedby a WINDOWS host, after authorized loading onto a HSM, and vice-versa.

Session

An interactive information exchange between a client and server, or (Oracle) database and user, using aconnection.

Softcard

A softcard is similar to an OCS card in so far as it can be used to protect encryption keys, in this caseusing a software token, a passphrase, and Security World protecting key. Unlike an OCS card, thesoftcard is not a physical object. It is software based and singular. Each softcard works on its own.

Structured Query Language (SQL)

SQL is a programming language used to write database queries or perform other programming actionsrequired from a database. Different database providers may use different variants of SQL, hence SQLused for one provider’s database may not necessarily work with another provider’s database.

Transparent Data Encryption (TDE)

A method of automatically encrypting data before it is stored on disk, and automatically decrypting databefore it is returned to working memory. This is ‘transparent’ because it can be done without affectingSQL operations (with some restrictions), and authorized database users need not be aware of itsfunctioning.

Trusted Verification Device (TVD)

Required for Remote Administration (see "Remote Administration (RA)" on the previous page). A TVD is aJava Card reader with a display that allows the card holder to securely confirm the Electronic SerialNumber (ESN) of the HSM to which they want to connect. It also includes an on-board firewall. nCiphersupplies a Trusted Verification Device and recommends its use with Remote Administration.


D Glossary

Wallet (software)

(Pre Oracle version 12c terminology). Effectively same as ‘Keystore’.

See "Keystore (software)" on page 95.


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 Security

Today’s fast moving digital environment enhances customer satisfaction, gives competitive advantage and improvesoperational efficiency. It also multiplies the security risks. nCipher Security, a leader in the general purpose hardwaresecurity module (HSM) market, empowers world-leading organizations by delivering trust, integrity and control to theirbusiness critical information and applications.

Our cryptographic solutions secure emerging technologies – cloud, IoT, blockchain, digital payments – and help meetnew compliance mandates, using the same proven technology that global organizations depend on today to protectagainst threats to their sensitive data, network communications and enterprise infrastructure. We deliver trust for yourbusiness critical applications, ensuring the integrity of your data and putting you in complete control – today, tomorrow, atall times. www.ncipher.com

Oracle Database Integration Guide · Solaris11.3.Oracle Solaris11.3couldnot betestedforkey...

Documents

Transcript of Oracle Database Integration Guide · Solaris11.3.Oracle Solaris11.3couldnot betestedforkey...