UKOUG, 06.12.2017 Introduction to Oracle Key Vault

3 Membership Tiers • Oracle ACE Director • Oracle ACE • Oracle ACE Associate bit.ly/OracleACEProgram 500+ Technical Experts Helping Peers Globally Connect: Nominate yourself or someone you know: acenomination.oracle.com @oracleace Facebook.com/oracleaces oracle-ace_ww@oracle.com

About me • (Sve)toslav Gyurov • Professional services consultant at Red Stack Tech (DI), UK • Started with Slackware 3.6 (kernel 2.0.34) • System engineer for 8y • HP-UX 11i v2 and Oracle 10g later • GTD and 7 Ps (Proper Planning and Preparation Prevents Piss Poor Performance) • Twitter - @sgyurov • Blog - http://sve.to • Futurama and Friends big fan

Why do we need encryption • Everyone has different reasons • User's identity, privacy, medial records and so on • Securely protect any kind of data • Address security-related regulatory compliance (like GDPR)

Oracle TDE • Enables you to encrypt sensitive data • Data is transparently encrypted and decrypted (hence TDE) • Can be applied on a column or whole tablespace • Encrypts data stored in data files (data at rest) • Unauthorized users, cannot read the data from storage and back up media unless they have the encryption key to decrypt it • To prevent unauthorized decryption, the encryption keys are stored in a security module external to the database, called a keystore

Oracle TDE • Database supports both software and hardware (HSM) keystores • Three types of software keystores • Password-based software • Auto-login software keystores • Local auto-login software keystores • Hardware Security Module (HSM) • Oracle Key Vault

TDE keys TDE relies on two distinct sets of encryption keys: • Data encryption keys (DEK), which are used to transparently encrypt and decrypt stored data (3DES168, AES128, AES192, or AES256) • Key encryption keys (KEK), also known as TDE master keys (AES256)

How TDE works 1. TDE tablespace encryption uses the two-tiered, key-based architecture 2. TDE master encryption key is stored in an external security module 3. This TDE master encryption key is used to encrypt the TDE tablespace encryption key 4. Which in turn is used to encrypt and decrypt data in the tablespace

TDE and 12c CDB • Multiple PDBs can access a single keystore • Each PDB using encryption has a TDE master encryption key stored in the keystore • You must manage the TDE master encryption key for each PDB from within the PDB only • Most of the keystore operations are performed from the root container How Transparent Data Encryption Works in a Multitenant Environment: https://docs.oracle.com/cloud/latest/db121/ASOAG/asotrans_other.htm#A SOAG10353

TDE overhead • Storage overhead • Minimal with column encryption • No overhead with tablespace encryption • Performance • Starting with 11.2.0.2 Oracle is able to use the hardware crypto acceleration features of the Intel XEON 5600 processors (AES-NI) • License • You need Advance Security Option

Oracle Keystore (wallet) • Encrypted container that is used protect the TDE master key • If the keystore is not open, the database will return an error when TDE protected data is queried • Data is encrypted in REDO logs, UNDO and TEMP tablespaces, the TDE master encryption key needs to be available to the database before it is opened • Backup! Backup! Backup!

Software keystore Password-based wallet is an encrypted key storage file (ewallet.p12) that follows the PKCS #12 standard. It is encrypted by a password-derived key according to the PKCS #5 standard – starting with 12.1.0.2 password is encrypted using AES256 Auto-login wallets (cwallet.sso) optionally are derived from standard password-based wallets for special cases where automatic startup of the database is required with no human interaction to enter a wallet password. For local auto-login keystores - When creating keystore with LOCAL option, the keystore can only be opened in the computer where it was created.

Hardware keystore • Hardware Security Modules (HSM) used to secure keys and perform cryptographic operations • Oracle interfaces to the device using a PKCS#11 library supplied by the HSM vendor • When using an HSM, all operations that use the TDE master encryption key are performed inside the HSM • This means that the TDE master encryption key is never exposed in insecure memory

Oracle Key Vault • A centralized platform to securely store and manage encryption keys • Will help you deploy encryption across your enterprise quickly and efficiently • Prevent the loss of keys and wallets due to forgotten passwords or accidentally deleted wallets and keystores • Allows you to retain, backup, restore and manage security objects and their lifecycle in a protected environment • It complies with the industry standard Key Management Interoperability Protocol (KMIP) • Support for Oracle Cloud Database as a Service instances in a hybrid cloud topology

OKV Installation • Oracle Key Vault is packaged as a software appliance • Install on a bare metal or virtual machine • Latest version of Oracle Key Vault is 12.2.0.5.0 (OEL 6.9) • Simple installation, takes less than an hour • Prepare network parameter and strong passwords Oracle Key Vault 12.2.0.5.0 consists of the following ISO files: V930304-01.iso (Oracle Key Vault 12.2.0.5.0 (12.2 Bundle Patch 5) - Disc 1) V930305-01.iso (Oracle Key Vault 12.2.0.5.0 (12.2 Bundle Patch 5) - Disc 2)

OKV Endpoints • Computer systems like database servers, application servers • Must be registered and enrolled to communicate with Oracle Key Vault • Set the Default Wallet for an Endpoint • Downloading and installing the endpoint software (okvclient.jar) • Grant an Endpoint Access to a Virtual Wallet

OKV Users • Separation of duties • Ordinary users – access to one virtual wallet only • Administrative Roles • System Administrator • Key Administrator • Audit Manager • Combined in one user

OKV Virtual Wallets • Is a container for security objects like public and private encryption keys • OKV provides mechanism for sharing with multiple users, endpoints or groups • Various levels of access – read only, read and write, manage wallet

OKV High Availability • Avoid single point of failure • Avoid the press • Ideally you want two of those to protect your precious keys • Setup only takes couple of minutes (it is a small database) • Using ssh key authentication and Dataguard under the hood • Allows Read-Only Restricted Mode and Fast Start Failover

OKV High Availability • Creating standby takes less than 10 mins • Switching roles takes less than 5 mins DGMGRL> show configuration; Configuration - DBFWDB Protection Mode: MaxAvailability Members: DBFWDB_HA1 - Primary database DBFWDB_HA2 - (*) Physical standby database Fast-Start Failover: ENABLED Configuration Status: SUCCESS (status updated 57 seconds ago)

OKV Backup and Recovery • Like any other database you need to backup OKV! • Local or remote (over ssh) • One-off or scheduled backups • Restore requires new OKV installation • The maximum life of a backup is 1 year. Any backup older than a year cannot be restored.

OKV and HSM • With HSM, the Root of Trust (RoT) remains in the HSM • HSM RoT protects the wallet password, which protects the TDE master key, which protects the encryption keys • Three tier hierarchy greatly mitigates the risk of physically accessing the keys • Supported HSMs: • SafeNet Luna SA 7000 and Thales nShield Connect 6000 • An existing Oracle Key Vault deployment cannot be migrated to use an HSM

How OKV works

OKV for Oracle DB Centralized management of TDE master keys over a direct network connection Known as Online Master Keys (TDE Direct Connect)

Ok but HOW really works The Master Key : What happens when the master key is used, accessed and reset in TDE ? (Doc ID 1342875.1) Persistent cache: https://docs.oracle.com/cd/E65319_01/OKVAG/release_ch anges.htm#GUID-720BC5A5-14DB-42ED-9B34- 94422FFCEF80

Real world implementation

Customer use case • Big insurance company • OKV deployed in two location (primary and DR) • Using Exadata X5-2 for production and DR • Running 20+ production and 50+ dev databases • TDE deployed across the board • Moving away from local keystores to OKV

TDE and Exadata • Content is always encrypted on the compute nodes • Decryption usually takes place in the compute nodes • However sometimes the tablespace keys are pushed to the storage cells • Contents can be first decrypted and then, Smart Scan is applied

Create new databases using OKV • Configure OKV integration and create virtual wallet • Open the OKV wallet and generate master key • Close the wallet • Generate auto-login wallet • Restart the database • Create encrypted tablespace

Migrate existing databases to OKV • Now this will take some time and planning • Configure OKV integration and create virtual wallet • Goes over couple of stages • Requires two reboots • Primary done first and then the standby

CHALLENGES

TDE and RMAN backups • RMAN restore does not decrypt TDE data when backing it up • Not the case if you are taking compressed backup! • Blocks needs to be decrypted first, compressed and encrypted again • RMAN recover does needs the TDE keys • Manually open the keystore or use auto-login keystore ORA-19913: unable to decrypt backup ORA-28365: wallet is not open. Does Rman Re-Encrypt TDE (Tablespace) Encrypted Data? (Doc ID 819167.1)

TDE and RMAN duplicate • RMAN duplicate might fail with wallet is not open error • If performing manual restore then open the keystore • For RMAN DUPLICATE you will need auto-login keystore ORA-19913: unable to decrypt backup ORA-28365: wallet is not open. RMAN Duplicate Using TDE Encrypted Backups (Doc ID 1560327.1)

RMAN table restore • Automatic operation • Auxiliary database gets a random name • Cannot use auto-login wallet • SR in progress to seek a solution

Instance crash in 12.1.0.2 ORA-00600: internal error code, arguments: [kcrf_decrypt_redokey_3], [], [], [], [], [], [], [], [], [], [], [] ORA-28407: Hardware Security Module failed with PKCS#11 error CKR_GENERAL_ERROR(%d) Patch 24804281: SHARE REDO LOGS KEYS B/W REDO LOG FILES

Deleting a key or a keystore (NOT) Once created, the TDE keystores should never be deleted, even when there are no encrypted objects in the database. How to delete old master keys from 12c TDE keystore (wallet). (Doc ID 2216279.1)

Plain data in data files ?! • During the lifetime of a table, data may become fragmented, re- arranged, sorted, copied and moved within the tablespace • This leaves 'ghost copies' of your data within the database file. • When encrypting an existing column, only the most recent 'valid' copy is encrypted, leaving behind older clear-text versions in ghost copies. • If the data file holding the tablespace is directly accessed bypassing the access controls of the database (for example with an hex editor), old clear text values might be visible for some time

Further reading and questions Master Note For Transparent Data Encryption ( TDE ) (Doc ID 1228046.1) Known TDE Wallet Issues (Doc ID 1301365.1) http://sve.to

Red Stack Tech 218A Moulsham Street Chelmsford Essex CM2 0LR Tel: +44 (0)844 811 3600 Web: www.redstk.com Email: contactus@redstk.com