Securing Voice and Data Networks
December 2005 Issue The answer lies in standards. By Wim De Ketelaere and Luc Martens, tComLabs Cable networks were originally deployed to offer broadcast services to homes. Because it was a one-way broadcast service, privacy of the content was of no concern. With the introduction of new services such as high-speed Internet and telephony, security became a major concern for the operator. To provide interactive services, cable networks were upgraded to have a return path. Interactive services pose different security requirements. The cable network is now used to carry private information, such as email, Web pages and phone calls. Having high-speed Internet service without paying for it is the main threat for the operator. Privacy of user data is another big concern; it would be unacceptable if hackers could intercept data or eavesdrop on voice calls. For telephony services, authentication of the device that actually made the call so it can be properly billed is also of very high importance. Baseline privacy DOCSIS is the de facto standard for delivering Internet protocol (IP)-based services over the cable network. Euro-DOCSIS is based on the DOCSIS protocol, but adapted the physical layer to be more suited for European hybrid fiber/coax (HFC) networks. The discussion that follows applies to both standards. DOCSIS defines the interfaces and related management interfaces and variables between a cable modem termination system (CMTS) and cable modem. A CMTS transmits a modulated downstream signal that is received and demodulated by all cable modems. A cable modem inspects the headers of each packet and makes a forwarding decision based on the destination media access control (MAC) address. It is clear that without some additional security mechanisms, it would be easy to build devices (hacked modems) that forward all packets. The device would need to be able to demodulate the downstream signal and parse the data correctly. The Baseline Privacy Interface (BPI) defines the mechanism to protect data privacy across the HFC network. It is part of the DOCSIS 1.0 set of specifications. The mechanism to provide data privacy across a shared medium is the use of encryption, which typically involves the use of a shared secret or key. A shared key, though, is not always necessary; when private-public key technology is used, no shared key is needed. Algorithms that work using private and public keys are computationally much more intensive and will therefore typically not be used for the actual data encryption. The second mechanism is the secure distribution of this shared key. For electronic devices, this can be done by logging in into each individual device and entering the shared secret on each device. If secure individual communication needs to be possible between many devices, each device must have a unique key for the other devices; entering these keys manually would become an operational nightmare. In the case of CMTS to cable modem communications, it would mean that a unique shared secret must be manually entered between each cable modem and the CMTS it is connected to. This clearly is not a scalable approach. The mechanism used in the BPI specification is based on the use of public-private key cryptography to distribute a shared key between modem and CMTS. During registration, the modem sends a message to the CMTS to request a shared key; this message contains a public key that can be dynamically generated by the modem. The modem stores the matching private key for use in the next steps. The CMTS generates a shared key (called the Auth-Key) and encrypts this key using the public key sent by the modem. Because the modem is the only entity that has the matching private key, the specific cable modem is the only device that can decrypt the message. From that moment on, the modem and CMTS share a secret key. This Auth-key is then used between modem and CMTS to exchange a new set of keying material called the TEK-key (traffic encryption key); it is used to encrypt the actual data packets using the data encryption standard (DES) algorithm using CBC (cipher block chaining) mode. Authentication The weakness of this approach is that the modem is not authenticated to the CMTS. The acceptance of the modem in the system (both provisioning system and CMTS) is based on the MAC address that the modem used to identify itself, but this approach does not contain a mechanism to authenticate this MAC address. The BPI+ specification addresses this problem by the use of digital certificates. A digital certificate is a structure that contains (among other things) identification information (the subject), a public key, issuer information and a signature. This signature is generated by the certificate issuer using public-private key technology. The issuer signs a certificate using its private key. To verify the signature, the public key of the issuer is needed. Using this technology, a structure can be defined where a trusted third party (the root) signs a certificate from a specific entity, and this entity further signs certificates from sub-entities. A party that receives the certificate from the sub-entity first verifies the signature using the public key from the entity, which is contained in the entity’s certificate. The public key from this entity is authenticated by verifying the signature of the entity’s certificate by the use of the public key of the root (the trusted third party). Within DOCSIS 1.1 or 2.0, this is exactly the mechanism that is used and illustrated in Figure 1. The DOCSIS root certificate signs certificates of manufacturers of DOCSIS cable modems (Mfg Cert), and the manufacturers sign at the manufacturing facility the certificates of each cable modem. Each cable modem has a unique certificate and public-private key pair. During registration, the cable modem sends the manufacturer certificate and its own certificate (which includes the MAC address of the cable modem) to the CMTS; the CMTS verifies both certificates using the public key of the DOCSIS root certificate (this needs to be loaded onto the CMTS) and uses this authenticated public key to encrypt the Auth-Key that is sent to the cable modem. . 
The procedure continues in the same way as normal BPI operation as described earlier. The important difference with this procedure is that the cable modem’s MAC address is now authenticated to the CMTS: Because the manufacturer signed a certificate that links the MAC address to the public key, and because only that modem can have the matching private key, only that cable modem will be able to decrypt the message back from the CMTS, so only that cable modem can have that MAC address. Security in PacketCable PacketCable is the set of specifications that defines all interfaces (security, signaling, quality of service and so on) to offer telephony services over the HFC network using voice over IP (VoIP) technology. The architecture is shown in Figure 2. The call management server (CMS) is the component that is responsible for all decisions regarding the telephony signaling. The devices placed at the customer premises (multimedia terminal adapter, or MTA) also contain a unique digital certificate to authenticate them to the different servers in the network. Because the architecture contains multiple servers for the different functions, the authentication for the different systems is centralized in the key distribution center (KDC) server, and Kerberos is used as the protocol to make this system scalable. Within this architecture, the different servers also authenticate to the MTAs using their own digital certificate hierarchy. By authenticating the servers to the MTAs, a hacking attempt by spoofing a server is prevented. 
Because BPI uses DES encryption (which is considered to be weak) and is only on the HFC-network, the voice packets themselves are encrypted using the Advanced Encryption Standard (AES) protocol. The call signaling itself is protected using the IPsec standard using triple-DES (3-DES) as the encryption protocol. Because billing is an important aspect of telephony services, the PacketCable architecture bases all billing on information obtained from trusted (that is, devices within the premises of the operator) devices. Mechanisms are also available that prevent users from using QoS on the cable network (such as so-called half-calls) without properly paying for it. Enabling security Using encryption and digital certificates creates potential interoperability problems when deploying components from different manufacturers and when these components are not fully compliant with the DOCSIS or PacketCable specifications. Therefore, field engineers switch off the security mechanisms many times “to get things working.” While this is useful to identify specific issues that are related to other parts of the system, it is bad practice to leave the operational network unprotected because it poses significant risks to the services and the business. By properly implementing the mechanisms defined in the DOCSIS and PacketCable (and Euro-DOCSIS and Euro-PacketCable) standards, operators can protect their networks from theft of service and privacy attacks. Too many times, the security mechanisms are switched off because they are considered burdensome. Neglecting security, however, only creates additional problems. The burden of having to recover from one successful attack on the network might be all the heavier. Wim De Ketelaere is CTO and Luc Martens is CEO for tComLabs. Reach them at [email protected] and [email protected].
