The SPA IP Phones as well as SPA ATA Gateways can do end-to-end encryption of audio stream. Such mode of operation is available even in the recent models, but no details are documented in recent documentation. The following description has been taken from ancient revision of Linksys ATA Administration Guide. It may help to someone wishing to implement support for it in a open-source softswitches like FreePBX or Asterisk
Note that the s-descriptor style of SRTP is end-to-next-hop encryption only, not the end-to-end. As ZRTP, the another end-to-end encryption has been implemented in no hardware VoIP phone, the legacy x-sipura seems to be the only solution available in hardware VoIP end-device.
Secure Call Implementation This section describes secure call implementation with a Linksys ATA device. It includes the following topics:
NOTE: This is an advanced topic meant for experience installers. See also the LVS Provisioning Guide.
Enabling Secure Calls A secure call is established in two stages. The first stage is no different from normal call setup. The second stage starts after the call is established in the normal way with both sides ready to stream RTP packets.
In the second stage, the two parties exchange information to determine if the current call can switch over to the secure mode. The information is transported by base64 encoding embedded in the message body of SIP INFO requests, and responses using a proprietary format. If the second stage is successful, the Linksys ATA device plays a special Secure Call Indication Tone for a short time to indicate to both parties that the call is secured and that RTP traffic in both directions is being encrypted.
If the user has a phone that supports call waiting caller ID (CIDCW) and that service is enabled, the CID will be updated with the information extracted from the Mini-Certificate received from the remote party. The Name field of the CID will be prepended with a ‘$’ symbol. Both parties can verify the name and number to ensure the identity of the remote party.
The signing agent is implicit and must be the same for all Linksys ATA devices that communicate securely with each other. The public key of the signing agent is pre-configured into the Linksys ATA device by the administrator and is used by the Linksys ATA device to verify the Mini-Certificate of its peer. The Mini-Certificate is valid if it has not expired, and it has a valid signature.
The Linksys ATA device can be configured so that, by default, all outbound calls are either secure or not secure. If secure by default, the user has the option to disable security when making a call by dialing *19 before dialing the target number. If not secure by default, the user can make a secure outbound call by dialing *18 before dialing the target number. However, the user cannot force inbound calls to be secure or not secure; that depends on whether the caller has security enabled or not.
The Linksys ATA device will not switch to secure mode if the CID of the called party from its Mini-Certificate does not agree with the user-id used in making the outbound call. The Linksys ATA device performs this check after receiving the Mini-Certificate of the called party
Secure Call Details Looking at the second stage of setting up a secure call in greater detail, this stage can be further divided into two steps.
1.The caller sends a “Caller Hello” message (base64 encoded and embedded in the message body of a SIP INFO request) to the called party with the following information:
Message ID (4B)
Version and flags (4B)
SSRC of the encrypted stream (4B)
Upon receiving the Caller Hello, the called party responds with a Callee Hello message (base64 encoded and embedded in the message body of a SIP response to the caller’s INFO request) with similar information, if the Caller Hello message is valid. The caller then examines the Callee Hello and proceeds to the next step if the message is valid.
2.The caller sends the “Caller Final” message to the called party with the following information:
Message ID (4B)
Encrypted Master Key (16B or 128b)
Encrypted Master Salt (16B or 128b)
The Master Key and Master Salt are encrypted with the public key from the called party mini-certificate. The Master Key and Master Salt are used by both ends for deriving session keys to encrypt subsequent RTP packets. The called party then responds with a Callee Final message (which is an empty message).
The MC has a 512-bit public key used for establishing secure calls. The administrator must provision each subscriber of the secure call service with an MC and the corresponding 512-bit private key. The MC is signed with a 1024-bit private key of the service provider, which acts as the CA of the MC. The 1024-bit public key of the CA signing the MC must also be provisioned for each subscriber.
The CA public key is used by the Linksys ATA device to verify the MC received from the other end. If the MC is invalid, the Linksys ATA device will not switch to secure mode. The MC and the 1024-bit CA public key are concatenated and base64 encoded into the single parameter Mini Certificate. The 512-bit private key is base64 encoded into the SRTP Private Key parameter, which should be kept secret, like a password. (Mini Certificate and SRTP Private Key are configured in the Line tabs.)
Because the secure call establishment relies on exchange of information embedded in message bodies of SIP INFO requests/responses, the service provider must ensure that the network infrastructure allows the SIP INFO messages to pass through with the message body unmodified.