© 2003 - 2005 Sipura Technology, Inc
Proprietary (See Copyright Notice on Page 2)
85
Notes:
1. These codes automatically appended to the dial-plan. So no need to include them in dial-plan
(although no harm to do so either).
3.5.9.6. Secure Call Implementation:
A secure call is established in two stages. The first stage is no different form a normal call setup.
Right after the call is established in the normal way with both sides ready to stream RTP packets, the
second stage starts where 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 and embedding
in the message body of SIP INFO requests and responses with a proprietary format. If the second
stage is successful, the SPA will play a special “Secure Call Indication Tone” for short while to
indicate to both parties that the call is secured and that RTP traffic in both directions are encrypted. If
the user has a CIDCW capable phone and CIDCW service is enabled, then the CID will be updated
with the information extracted from the Mini-Certificate received from the other end. The Name field of
this CID will be prepended with a ‘$’ symbol.
The second stage in setting up a secure all can be further divided into two steps. Step 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)
- Mini-Certificate
(252B)
Upon receiving the Caller Hello, the callee 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 step 2 if the message is valid. In step 2 the caller sends the “Caller Final” message to the
callee with the following information:
-
Message ID (4B)
-
Encrypted Master Key (16B or 128b)
-
Encrypted Master Salt (16B or 128b)
With the master key and master salt encrypted with the public key from the callee’s mini-certificate.
The master key and master salt are used by both ends for the derivation of session keys for
encrypting subsequent RTP packets. The callee then responds with a Callee Final message (which is
an empty message).
A Mini-Certificate contains the following information:
-
User Name (32B)
-
User ID or Phone Number (16B)
-
Expiration Date (12B)
-
Public Key (512b or 64B)
-
Signature (1024b or 512B)
The signing agent is implicit and must be the same for all SPA’s that intended to communicate
securely with each other. The public key of the signing agent is pre-configured into the SPA’s by the
administrator and will be used by the SPA to verify the Mini-Certificate of its peer. The Mini-Certificate
is valid if a) it has not expired, and b) its signature checks out.
