11.10  
Signaling & Payload Encryption (SPE) 
 

Overview  
These features are provided in HiPath 3000/5000 V7 R4 and later systems. Both signaling and user data can be encrypted in the LAN on a subscriber-specific basis.
Signaling & Payload Encryption (SPE):
 •   Signaling encryption: Signal transmission between gateways (HG 1500) and clients is encrypted with a 128-bit key. The TLS protocol with AES encryption is used for the transmission. The same mechanism (TLS and AES) is used for IP networking.
 •   Payload encryption: User data, also referred to as voice data or payload, is transferred via Secure Real-time Transport Protocol (SRTP). This data is encrypted with a 128-bit key (AES). SRTP is also used for IP trunking (HG1500). The key exchange procedure for SRTP is called Multimedia Internet Keying, or MIKEY for short.

Licensing  
 •   Signaling encryption: No licenses are required to encrypt signaling data. This applies to HFA, H.323, SIP and IPDA signaling connections, as well as to the CTI interface.
 •   Payload encryption: For encryption of user data a ComScendo Security license is required per station and B-channel (Gateway channel). The ComScendo Security license is generated automatically on the Central License Server (CLS) and does not cause any additional costs.

Encryption Algorithms  
The AES and RSA algorithms used for encryption have key lengths of 128 or 1024 bits respectively. The former algorithm is symmetrical while the latter is asymmetrical. The RSA algorithm resolves the problem of swapping keys that the AES should use. The telephones do not exchange the keys directly with one another; instead they are exchanged via the gateway; therefore generating a pair from a public and private key per telephone from each one is unnecessary. User and signaling data is encrypted with AES.

Encrypting Signaling Data  
Certificates can be generated with the Deployment License Service (DLS) and distributed to gateways; certificates can also be manually loaded in the gateways. Certificates should vouch for the authenticity of a sender.
An IP phone logs on to the gateway (GW) as soon as it connects to the corporate LAN. This is the case as long as a DLS is entered in the Dynamic Host Configuration Protocol (DHCP) or the relevant settings have been made manually on the telephone or by using the web access. The IP phone next sets up a permanent server-authenticated TLS connection to the GW; the IP phone then receives the certificate from the GW. Certificates do not need to be encrypted - only the private key remains secret as it never leaves the GW. The IP telephone verifies the validity of the system certificate (SPE certificate) based on the date and time. The IP telephone can also verify whether the Certificate Authority (CA) for the SPE certificate is a trusted source. To this end, the SPE CA certificate must be installed on the IP telephone using DLS.
The SPE CA certificate only contains the public key for the gateway. Once the TLS connection has been established, all signaling data is exchanged with the GW via this encrypted connection. This includes, for example, registration and call setup.
In order to encrypt the application data, every TLS connection uses a session key. This works as follows: the client - in this case the IP phone - dials a sufficiently long pseudo-random number and encrypts it with the public key from the GW certificate. This encrypted random number can only be decrypted by the GW with its private key. The session key is then generated on both sides using the selected random number.
The encrypted connection remains active as long as the IP phone is logged on to the GW. However, the session key is renegotiated at regular intervals (standard: every 24 hours).

Encrypting user data  
The IP phone dials the number of the remote station. During call setup, the IP phone transfers a Mikey container first to the GW and then from the GW to the remote station. The Mikey container contains the key used to symmetrically encrypt data for an SRTP connection. Both IP telephones establish a direct SRTP connection with each other that is secured using the key that was exchanged in the MIKEY container. Each newly-established call is encrypted using another key. In other words, a pseudo random number is generated for each telephone call.
One important special case is telephone conferences. These are transmitted with full encryption and indicated as secure calls if all participating IP telephones can use the encryption. If an unencrypted section of a route (e.g. a non-encrypted IP telephone or an ISDN trunk) participates in the conference, Standard Call is displayed for all conference participants, even if their individual route sections remain encrypted.
Keys are only swapped by stations that use encryption. The users cannot activate or deactivate encryption themselves.

Signaling & Payload Encryption (SPE) on HG1500  
The HG1500 gateway requires the following data for the Signaling & Payload Encryption (SPE) feature:
 •   For VoIP:
   -   A gateway-specific, private key and a certificate
   -   A list of authentic CA certificates
 •   Optional: A CRL Distribution Point (CDP) and the corresponding CRL (Certificate Revocation List)
 •   A security policy to be agreed upon with the customer
 •   Optional: Data (SecureTracePassphrase) for configuring secure trace via WBM
 •   Flag for SPE support: If activated, encryption for IP-based telephones and trunks is activated by default, provided the required PKI data is available.
 •   The security level (traditional or secure) supported by each partner gateway

Upgrade  
The Signaling & Payload encryption feature is provided in HiPath 3000/5000 V7 R4 or higher. If a software version lower than V7 R4 is in use, it must be upgraded before the SPE feature can be used in HiPath 3000. Please refer to the published release notes.
Hardware does not need to be upgraded. As a result of the increased demand by SPE for resources further HG 1500 boards might be required.

Telephone Encryption  
Signaling & Payload Encryption is only supported by HFA terminals. The following HFA telephones support the encryption:
 •   optiPoint 410 (not optiPoint 410 entry or optiPoint 410 economy)
 •   optiPoint 420 (not optiPoint 420 economy)
 •   OpenScape Personal Edition
 •   OpenStage 20 E, 20, 20 G
 •   OpenStage 40, 40 G
 •   OpenStage 60, 60 G
 •   OpenStage 80, 80 G
Analog fax machines or modems can be connected to the corporate LAN via the HiPath AP 1120 IP adapter. HiPath AP does not support encryption but can still be operated in the corporate network.

Configuration of the IP terminals  
An IP terminal can be configured from one of the following types of IP clients:
Standard client:  
Unsecured terminal.  
SRTP (voice encryption) and signaling encryption (TLS-secured) is not supported.  
Secure client:  
Full encryption (SRTP and TLS secured)  
Also supports unsecured terminals and terminals secured only for signaling (TLS secured).  

TDM terminal configuration  
A TDM terminal is generally classified as standard client but can also be configured as a secure client by activating the "payload security" flag.
Configuring analog and TDM terminals does not influence their behavior. This configuration is aimed only at detecting "IP/IP e2e payload via enterprise proxy" encryption.
Using the "payload security" flag you can set on OpenStage TDM terminals whether to display when part of a connection path to an IP station is encrypted. It is not possible to encrypt signaling and voice data along the entire connection path for OpenStage TDM terminals. Setting the "payload security" flag for all other TDM terminals has no function.

Display  
Users can see whether or not encryption is in use at the beginning of a call based on the information displayed on their IP workpoints. The display of whether or not encryption is in use for a call can be deactivated throughout the system if desired.
The encryption status can also be displayed by pressing a key or via the telephone menu.

 Table 11-1   Signaling & Payload Encryption SPE - status display  
 IP workpoints  
 Shown in display  
   
 Encrypted call  
 Non-encrypted call  
OpenStage 20 E, 20, 20 G,
40, 40 G, 60, 60 G and 80, 80 G  
(CorNet-IP connection variant)  
 Lock symbol  
 •   OpenStage telephone that supports SPE:
Lock symbol crossed out
 •   OpenStage telephone that does not support SPE: no display
optiPoint 410  
(not optiPoint 410 entry or optiPoint 410 economy)  
 Secure call  
 Standard call  
optiPoint 420  
(not optiPoint 420 economy)  
Note: For OpenStage TDM telephones, the flag "Payload Security" can be used to configure whether the display should notify the user when part of the connection route to an IP station is encrypted. The encryption of signaling and voice data is, however, not possible for the entire connection path.

Model-Specific Data  

 Subject  
 HiPath 3800  
 HiPath 3550  
 HiPath 3500  
 HiPath 3350  
 HiPath 3300  
Feature available in  
 x  
 x  
 x  
Hardware requirements  
 -  
Software requirements  
 V7 R4 and later  
 V7 R4 and later  
 V7 R4 and later  

Dependencies/Restrictions  

 Subject  
 Dependency/Restriction  
Transit nodes that do not support SPE  
A connection between two nodes on which SPE is configured (for example, HiPath 3000 V7) can be established via a transit node that does not support SPE (for example, HiPath 3000 V5.0). In this case, the following connections are made:  
 •   Encrypted connection between the sending secure client and gateway (HG 1500 V7) of the source node
 •   Unencrypted connection between source and transit nodes
 •   Unencrypted connection between transit and destination nodes
 •   Encrypted connection between the gateway (HG 1500 V7) of the destination node and the receiving secure client
No H.323 trunking to systems without EFC  
Signaling & Payload Encryption (SPE) on H.323 trunks is only supported on systems using Extended Fast Connect (EFC).  
As the EFC concept is not implemented in HiPath 4000, IP trunking including SPE between HiPath 3000 and HiPath 4000 cannot be achieved via H.323 trunking - it must be achieved via SIP-Q trunking.  
Certificate checking  
A received certificate is only checked against the Certificate Revocation Lists (CRL) for which the CRL Distribution Point is configured. The CRL Distribution Point contained in the received certificate is not included.  
SPE certificates for 3rd-party public key infrastructure (PKI)  
SPE certificates for 3rd-party PKI must meet the following requirements in order to be used within the context of "SSL Client <-> SSL Server":
 •   SSL client
   -   Setting the extension "key usage extension" is not permitted. If "key usage extension" is set, "web client authentication" OID (object identifier) must be included.
   -   Setting "keyUsage" is not permitted. If "keyUsage" is set, "digitalSignature" must be configured.
   -   Setting "Netscape certificate type" is not permitted. If "Netscape certificate type" is set, "SSL client" must be configured.
 
 •   SSL server
   -   Setting the extension "key usage extension" is not permitted. If "key usage extension" is set, "web client authentication" OID (object identifier) and/or another OID must be included.
   -   Setting "keyUsage" is not permitted. If "keyUsage" is set, "digitalSignature" and/or "keyEncipherment" must be configured.
   -   Setting "Netscape certificate type" is not permitted. If "Netscape certificate type" is set, "SSL server" must be configured.
Note: The "extended key usage" policy cannot be removed from the Microsoft certificates. However it is possible to combine "ClientAuth" and "ServerAuth" in one certificate.
Limited number of supported IP clients  
Signaling and user data can be encrypted for up to 250 IP clients. Additional IP clients are not supported for the following reasons:  
 •   Concept of permanent TLS sessions for connecting IP stations and IP trunks
 •   50 KB additional memory required for each TLS session
 •   Limited gateway memory (HG 1500 V7)

HiPath 3000/5000 V9, Feature Description, Issue 7   up Top
Disclaimer & Copyright   ID: P31003H3590F100017618   2012-06-25