The SBC currently supports auto-tracing capabilities based on criteria such as Calling, Called Number, and Trunk groups or Served User. The SBC triggers auto-tracing and sends the calls to the SBC, which captures the call data in .TRC and .PKT files. Storing clear audio locally on the SBC creates security and privacy issues. This feature allows the auto-traced media streams to be encrypted to make sure that only certain parties can access the clear audio. You can enable or disable the encryption of the .PKT files, which means the output is clear audio (refer to the encryptFile parameter).
The SBC encrypts only the packet traces (.PKT files).
Traces captured on the standby node are encrypted with the same key used on the previously active instance.
When a call context is targeted for tracing, the SBC captures its media packets and stores the traced media stream in .PKT files. OpenSSL encrypts the media with a symmetric key (AES-128-CBC is the encryption algorithm) that the SBC creates and writes the media as encrypted data to the .PKT file. The SBC does not locally store clear audio media, which includes any .PKT file generated through other methods, that originates from auto-tracing.
The SBC can only locally store clear audio media that originates from auto-tracing if encryptFile
is disabled
(refer to Event Log - CLI). There may also be a scenario where clear audio is temporarily present even if a public key was configured (that is, the existing .PKT must rollover before the encryption starts).
You must configure the SBC with a public key (refer to the encryptionPublicKey parameter), which is part of the RSA public and private key pair that you generate (refer to setRsaKey and eventLogValidation, respectively).
The public key must be written in the SSH key format.
You must securely store and distribute the private key since it provides access to private data.
The SBC encrypts the symmetric key using the configured public key (refer to the encryptionPublicKey parameter), which means only the owner of the private key can access the symmetric key and decrypt the encrypted media file. The encrypted media file (.PKT file), the symmetric key file used to encrypt the media file, and the public key used to encrypt the symmetric key are bundled together. The symmetric key uses the same filename as the .PKT file but with the .KEY extension, and the public key uses the same filename as the .PKT file but with the .PEM extension. This bundle transfers to the Support Repository. You must decrypt the symmetric key with the private key, and then use the symmetric key to decrypt the .PKT file.
The following figure illustrates the auto-trace encryption feature.
Figure 1: Auto-trace Media Encryption
This section outlines how to decrypt the media file (.PKT file) using the symmetric key.
PrerequisitesThe private key file contains a passphrase that you must use to generate a symmetric key and initialization vector (IV), which you then use to encrypt and decrypt the .PKT files.
Enter the following command syntax to retrieve the passphrase in the private key file.
openssl rsautl -decrypt -inkey <private_key_file> -in <packet_file>.key > <packet_file>.key.dec
The following is an example command.
openssl rsautl -decrypt -inkey privatekey -in 1000018.PKT.key > 1000018.PKT.key.dec Contents of 1000018.PKT.key.dec HItxLUYIwDImDq8uIoLN++gZ6+AyBG94j3iaSEIMSwA=
Enter the following command syntax to decrypt the .PKT file with the passphrase.
openssl enc -md sha256 -d -aes-128-cbc -nosalt -in <packet_file> -out <packet_file>.dec -pass file:<packet_file>.key.dec
The following is an example command.
openssl enc -md sha256 -d -aes-128-cbc -nosalt -in 1000018.PKT -out 1000018.PKT.dec -pass file:1000018.PKT.key.dec
The decrypted .PKT file now contains the unencrypted PCAP file.