Your suggested change has been received. Thank you.

close
Thales Logo

All

  • All
  • CipherTrust Manager
  • CipherTrust Application Data Protection (CADP)
  • CipherTrust Application Key Management (CAKM)
  • CipherTrust Batch Data Transformation (BDT)
  • CipherTrust Cloud Key Management (CCKM)
  • CipherTrust Data Discovery and Classification (DDC)
  • CipherTrust Data Protection Gateway (DPG)
  • CipherTrust Database Protection (CDP)
  • CipherTrust Intelligent Protection (CIP)
  • CipherTrust Integrations
  • CipherTrust Migrations
  • CipherTrust RESTful Data Protection (CRDP)
  • CipherTrust Transparent Encryption (CTE)
  • CipherTrust Transparent Encryption Userspace (CTE-U)
  • CipherTrust Secrets Management (CSM)
  • CipherTrust Vaulted Tokenization (CT-V)
  • CipherTrust Vaultless Tokenization (CT-VL)
  • CTE-Linux
  • CTE-Windows
  • CTE-AIX
  • CTE-K8s
  • CTE-U
  • Crypto Command Center
  • Data Protection on Demand
  • Luna Cloud HSM
  • Luna Network HSM
  • Luna PCIe HSM
  • Luna USB HSM
  • OneWelcome Identity Platform
  • ProtectApp LUKS
  • ProtectServer 2 HSM
  • ProtectServer 3 HSM
  • SafeNet Trusted Access (STA)
  • SafeNet MobilePASS+
  • SafeNet MobilePASS+ for Android
  • SafeNet MobilePASS+ for Chrome
  • SafeNet MobilePASS+ for macOS
  • SafeNet MobilePASS+ for iOS
  • SafeNet MobilePASS+ for WatchOS
  • SafeNet MobilePASS+ for Windows
  • SafeNet Synchronization Agent
  • SafeNet Logging Agent
  • SafeNet Agent for FreeRADIUS
  • SafeNet Agent for NPS
  • SafeNet Agent for Windows Logon
  • SafeNet Authentication Service Private Cloud Edition (SAS PCE)
  • SafeNet Remote Logging Agent
  • SafeNet Keycloak Agent
  • SafeNet IDPrime Virtual (IDPV)
  • SafeNet FIDO Key Manager
  • SafeNet FIDO Key Manager for Android
  • SafeNet FIDO Key Manager for iOS
  • SafeNet FIDO Key Manager for Windows
back

Basic Troubleshooting Techniques

Verifying Database Encryption

search

Please Note:

Verifying Database Encryption

copy link to clipboardOption 1

The best way to verify the state of the data, without impacting anything in the existing environment, is to use the Oracle kfed command. You can run this command against the native path of the existing GuardPoints and make sure it returns with valid header information. If it returns valid information with the GuardPoint in place, then this confirms that the data is properly encrypted. If it returns with invalid header information, then that indicates that the data is either clear, double encrypted, or not in the expected encrypted state. The syntax for running this command would look similar to the following but will vary based on your environment.

/app/oracle/grid/product/19.0.0/grid/bin/kfed read /dev/rdisk/<diskName>

If the location is properly encrypted, following is an example of the viewable output:

/app/oracle/grid/product/19.0.0/grid/bin/kfed read /dev/rdisk/<diskName>

System Response:

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          242 ; 0x001: 0xf2
kfbh.type:                          124 ; 0x002: *** Unknown Enum ***
kfbh.datfmt:                         66 ; 0x003: 0x42
kfbh.block.blk:              1088904227 ; 0x004: blk=1088904227
kfbh.block.obj:              1558192170 ; 0x008: file=8234
kfbh.check:                  3321251423 ; 0x00c: 0xc5f6465f
kfbh.fcn.base:                932956641 ; 0x010: 0x379bc9e1
kfbh.fcn.wrap:               3040493590 ; 0x014: 0xb53a4016
kfbh.spare1:                 3806015223 ; 0x018: 0xe2db2ef7
kfbh.spare2:                 3794962182 ; 0x01c: 0xe2328706
60000000000D8000 01F27C42 40E75C23 5CE0202A C5F6465F
[..|B@.\#\. *..F_]
60000000000D8010 379BC9E1 B53A4016 E2DB2EF7 E2328706  [7....:@......2..]
60000000000D8020 CA2F30AD 522B4D21 99292639 004EBB34  [./0.R+M!.)&9.N.4]
60000000000D8030 A3896BE8 BD839D23 2204E19E 946C575C  [..k....#"....lW\]
60000000000D8040 4CE2218F 35E1B101 AF751A70 780E6D6E  [L.!.5....u.px.mn]
60000000000D8050 5E7E6A38 C600ED5F 929047C4 DF372A8E  [^~j8..._..G..7*.]
60000000000D8060 E103152D BA87CC03 11A7D963 9D72FCE1
[...-.......c.r..]
60000000000D8070 1EC6B48B 03EE869F 61D651F9 E7614957  [........a.Q..aIW]
60000000000D8080 810E0353 9C461F49 69569733 501D19EF  [...S.F.IiV.3P...]
60000000000D8090 B268002B 4F9457B6 BDB04AC5 D3D07446  [.h.+O.W...J...tF]
60000000000D80A0 FD9EE5E0 9B46CB66 30D10B22 F63AB77E  [.....F.f0..".:.~]
60000000000D80B0 6FF79075 4BBD1FAD 8F226188 7774300D  [o..uK...."a.wt0.]
60000000000D80C0 A809B6FB E1F1C80B B5760E68 9747D97D  [.........v.h.G.}]
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][124]

copy link to clipboardOption 2

The second option to verify the state of the data is to use the dd command. This requires you to specify some blocks and write it out to a file. After this completes, read the file using the strings command. You can do this while the device is in use. In the example below some sectors are skipped and it only dumps 10000 counts.

For example:

dd if=/dev/mapper/asm_data2p1 of=/tmp/dd2.out skip=1047 count=10000

copy link to clipboardOption 3

The third option to verify the state of the data without impacting the existing environment is to use the strings command.

note

Note

The strings command cannot read a busy or large device.

You can run this command against the native path (/dev/<deviceName>) of the existing GuardPoints (/dev/secvm/dev/<deviceName>). The new path to SecVM would be similar to /dev/secvm/dev/<deviceName>. By executing the strings command against the native path strings /dev/devicename | more, this does not go through the SecVM device and therefore is not be decrypted. If it is encrypted the output should contain illegible text.

On this page