Secure calling

By default, PortaSIP communicates with IP phones using the UDP protocol, so the contents of network packets exchanged between the server and endpoints are unencrypted. Therefore, if a third party can receive the packets (e.g., by being connected to the same Ethernet segment and running a network “sniffer” program), it can effectively see who is being called and listen to the whole conversation.

In order to prevent a third party being able to see SIP signaling information (e.g., call parameters such as the destination number), it is possible to use SIP over TLS. In this case, communication between the IP phone and PortaSIP is fully encrypted and cannot be decoded.

In order to ensure that nobody can listen to the actual voice conversation (transmitted as an RTP stream) the two IP phones can be configured to use the Secure Real-time Transport Protocol (SRTP RFC 3711) instead of basic RTP. The phones will then exchange voice data in an encrypted form, with PortaSIP simply passing packets from one phone to another, without analyzing the contents. Naturally, features such as call recording or music on hold will not be available for such conversations, since PortaSIP will not know the decryption key programmed into the IP phones.

No matter the method, the encryption keys are unique for each session. This is what eliminates the chance for a call to be intercepted and decrypted.

Media stream encryption is currently supported for “regular” calls and the following call features: three-way conferencing, call transfer, and call on hold. Support for other call features such as call pickup, call parking, IVR (e.g., pass-through IVR), etc. during encrypted calls will be added in future releases.

PortaSwitch media stream encryption increases call security and protects users from unwanted interception activities. It allows administrators to manage security settings for accounts, thus making it possible to provide secure calls among phones that have different capabilities.

With this functionality added, PortaSwitch can be easily integrated with WebRTC applications, thereby increasing the service provider’s competitiveness in the market.

This feature allows communication between an IP phone and PortaSIP to be encrypted so that it cannot be intercepted. This prevents a third party from being able to see SIP signaling information (e.g., call parameters such as the destination number).

Enabling SIP over TLS requires the generation of SSL certificates in order to validate that the secure connection is established to the server that it claims to be. In order to simplify administration and prevent companies from having to obtain these certificates from outside authorities such as Verisign, PortaSwitch can generate self-sign certificates. To renew them, PortaSwitch detects an approaching expiry date for the certificates and restarts the SIP server during the next configuration update.

These days the telecommunications market demands that secure calls be provided. If a user connects to a public WiFi hotspot and establishes a call from his soft phone, it is possible that a third party could intercept and/or listen in on the conversation. Therefore, it is necessary to protect such calls and guarantee their security by means of media encryption.

Another situation might be that a call established from an application that strictly requires media encryption reaches a phone that does not support media encryption.

To handle such cases and enable calls among devices with different capabilities to go through, PortaSwitch now performs intermediate media encryption. The system can be configured so that:

• PortaSwitch encrypts the media stream during a call and proxies it to a user’s device,
• PortaSwitch decrypts the media stream received from a user’s device before sending it to another party, or
• The media stream is encrypted by phones that use the Secure Real-time Transport Protocol (SRTP RFC 3711) instead of basic RTP. The encrypted media occurs directly among phones or is relayed by PortaSwitch without decryption (the so-called fully private call).

Let us have a closer look at the possibilities in more detail.

The key distinction of calls encrypted by PortaSwitch is that the RTP proxy always mediates the RTP media stream. This provides the RTP proxy with encryption keys, thus making it possible for a calling party’s media to be encrypted and then decrypted for a called party and vice versa. More complex call scenarios where a media stream must be encrypted for both call participants and their phones use different key agreement protocols that are also supported.

Consider the following example: John Doe calls his wife Jane from a phone that works only with encrypted media and supports encryption by zRTP. Jane’s phone, however, supports only SDES encryption. When the system authorizes the call, it detects that the media must be encrypted for both John and Jane and that the encryption methods differ. During the call, the media stream passes via the RTP proxy which has two sets of encryption keys. This allows PortaSwitch to receive encrypted media from John’s phone, decrypt it with the zRTP encryption keys, encrypt it using SDES encryption keys and send it to Jane’s phone.

During fully private calls the media stream is solely encrypted by users’ phones and delivered directly between these phones. If any of the phones is on a private network and the RTP proxy is involved in the call, it relays the media stream only, without decryption.

When establishing a fully private call, one must remember that:

• Both phones must support the same key agreement protocol.
• Since data is encrypted without the participation of PortaSwitch, account settings such as call recoding and music on hold are ignored because PortaSwitch does not decrypt the media stream.
• In the case that legal intercept functionality is configured for any of the accounts, PortaSwitch participates in the media transfer between the phones. However, since the media stream is encrypted without the participation of PortaSwitch, it stores the media stream encrypted and is unable to decrypt it.

The service policy configuration defines whether media encryption by PortaSwitch is required, and for which call participant – the caller, the callee or both. The following service policy options: caller_stream_relay_or_decrypt and callee_stream_security_settings define the security settings for the caller and callee, respectively.

Security settings, however, are applied separately to the calling and called parties. Thus, media stream processing for a calling party can be configured as follows:

• forced_relay – PortaSwitch relays the media stream received from the calling party and ignores the called party’s settings. The media features for the account such as music on hold, music on waiting and call recording are not available if the relayed media stream is encrypted.
• relay_or_decrypt – this is the default setting. PortaSwitch relays any type of media stream received from the calling party if it is allowed by the called party’s settings. Otherwise, the media stream is encrypted/decrypted.
• decrypt – PortaSwitch always decrypts the media stream received from the calling party.

The following are media stream processing configuration options for the called party:

• as_caller – this is the default setting. PortaSwitch relays any type of stream received from the calling party. The media features for the account such as music on hold, music on waiting and call recording are not available if the relayed media stream is encrypted.
• decrypted – PortaSwitch always decrypts/encrypts the media stream for the called party.
• sdes – PortaSwitch always performs media stream encryption for the called party using the SDES protocol.
• dtls – PortaSwitch always performs media stream encryption for the called party using the DTLS protocol.
• zrtp – PortaSwitch always performs media stream encryption for the called party using the zRTP protocol.

The decision to encrypt or relay a particular call depends on the security settings for the call originator. This allows you to fine tune the system for each specific case.

The results of the security setting configuration for both calling and called parties are provided in the table below:

The following key agreement protocols are supported:

• SDES
• DTLS
• zRTP

Each key agreement protocol has its own distinctive features yet the general flow is the exchange of cryptographic parameters between a device or an application and the RTP proxy.

When using the SDES key agreement protocol, the exchange of cryptographic parameters is performed during call initiation. The device that uses this key agreement protocol sends a set of randomly generated encryption keys to PortaSIP with the initial INVITE request. The RTP proxy negotiates one of the keys for media decryption and generates the local encryption key that is then delivered to the device in the confirmation response. These are the keys used for RTP media stream encryption.

When using the SDES key agreement protocol, SIP signaling support over TLS in PortaSwitch must be enabled and the device’s secure SIP signaling must be configured, accordingly.

The DTLS key agreement protocol is based on the Transport Layer Security (TLS) protocol. During call initiation, the user’s device and PortaSIP exchange IP:port information (just as for a regular RTP session). The negotiated IP:port pair is used to establish a secure DTLS connection which is the TLS over UDP plus special SRTP extension. Once established, it is used to negotiate cryptographic parameters. Those parameters are then used to establish a secure RTP media stream.

The zRTP key agreement protocol is similar to the DTLS. PortaSIP establishes a direct media path to the user’s device for the cryptographic parameters exchange. However, it does not require the involvement of signaling when establishing a secure media communication.

After the cryptographic parameters are exchanged, they are used for the RTP media stream encryption.