Dialogic 4000 Media Gateway Series SU4.1 Reference Guide
76
Secure RTP
Once a Voice over IP (VoIP) call is established, voice data is transported in packets with the
Real-time Transport Protocol (RTP). The voice data can be easily extracted from RTP
packets and replayed using commercially available software. SRTP adds security by
encrypting voice data and authenticating packets. Digital identity certificates are not
required, and the parameters are negotiated during call initiation time. SRTP mode is
activated typically in combination with TLS, but in some cases (e.g., testing, intranet
connections only) it is useful to allow SRTP also without TLS being activated.
For encryption and decryption of data, SRTP uses ciphers. The two parties involved in a
conversation must be "compatible" in the sense that each party understands the other
party's cipher requirements and supports them. Diva SIPcontrol supports the following
ciphers: DH, ADH, AES (128-256 bits), 3DES (64 bits), DES (64 bits), RC4 (64bytes), RC4
(256 bytes), MD5, SHA1.
SRTP can be set for each SIP peer in the security configuration. For information, see
Security Profiles. The cipher level can be set in the Global Security Parameters.
Using Certificates for Authentication and Data Encryption
For authentication and data encryption, certificates need to be installed on the computer on
which Diva SIPcontrol is installed and on remote computers. When a secure domain is
opened, server and client authenticate each other with a so called "SSL handshake". With
this handshake, the identity of a user is certified and it is assured that the user can be
trusted. All necessary certificates should be provided by a Certificate Authority (CA), and
they are issued for one domain name. For test purposes or internal usage, you can also
create and sign your own self-signed certificate, e.g., with one of the many tools available
on the internet. Search for "self-signed certificate" and you will find a list of possible tools.
But you need to be aware that self-signed certificates do not provide the same security as
CA-signed certificates. Also, many web browsers check if the certificate is signed by a CA,
and, if it is not, a warning message will appear asking whether the user really wants to trust
that web site, which can make the user feel insecure.
Certificate files can be generated in different formats, e.g., .pem, .der, .cer, or .pfx. All files
need to be in "pem" format (base64 encoded) in order to be used by Diva SIPcontrol.
A default certificate is provided with the software, but for security reasons, you should
install your own web server certificate.
Note for CER files: CER files can be renamed to .pem directly if they are base64 encoded.
No bag attribute lines and/or additional CR and empty lines are allowed. If CER files are
ASN.1 coded, they need to be converted to with a converter tool.
Note for PFX files: The PFX or PKCS#12 format is a binary format for storing the server
certificate, any intermediate certificates, and the private key in one encryptable file. When
converting a PFX file to PEM format, tools like OpenSSL will put all the certificates and the
private key into a single file. You will need to open the file in a text editor and copy each
certificate and private key (including the BEGIN/END statements) to its own individual text
file and save them as certificate.cer, CACert.cer, and privateKey.key respectively.
Kommentare zu diesen Handbüchern