Baseline Privacy Interface Plus
On a shared-access medium such as the one provided by cable companies, it is important that each user's data—both upstream and downstream—be protected from eavesdropping and alteration by other users of the same cable. In principle, there is nothing to stop a device attached to cable from eavesdropping on, and potentially capturing, passing traffic. At least in theory, it is possible for a malfeasant to attach a device to the cable in his own home and capture the digital traffic being transmitted and received by cable modems in nearby houses.15
In early, proprietary cable-based data systems there was sometimes no protection against such eavesdropping, leaving sophisticated computer users free to access information on other users' machines and also to examine the traffic passing along the coax. The current version of DOCSIS prevents this by implementing a mechanism called Baseline Privacy Interface Plus, BPI+. (An earlier incarnation was called the Baseline Privacy Interface. BPI1 is considerably more secure than BPI. It is mandatory to implement BPI1 on DOCSIS 1.1 compliant modems.)
BPI1 does not discriminate among the types of data flowing over the cable. All packets of user data transmitted over the cable are protected equally by the BPI1 security protocols. The mechanism used to secure communications between a CM and its corresponding CMTS is encryption of the traffic flows between the two devices.
BPI1 comprises two protocols.
-An encapsulation protocol, used for encrypting and decrypting the packets. This protocol defines the format for encrypted packets, the set of supported ciphersuites and the rules for applying the cryptographic algorithms to the packetized data.
-A key management protocol (Baseline Privacy Key Management, BPKM) that provides a secure method for distributing keying material between the cable modem and its CMTS.
The only encryption/decryption algorithm supported by the current version of BPI1 is the CBC mode of DES (see Chapter 2). Note that this is ordinary DES, not 3DES, and so is restricted to a 56-bit key.16 While adequate for ordinary use, this is insufficient to confound a well-funded, determined attacker. For this reason (as well as others) PacketCable does not rely merely on BPI1 to ensure the security of telephone conversations. Instead, PacketCable places another layer of stronger encryption on top of the BPI1 encryption.
BPI1 provides only encryption; it does not use any authentication algorithms. While this may be adequate for some services, it may not be so for a telephony service. Consequently PacketCable also adds authentication (as needed) to some of the flows associated with telephony traffic.
BPI1 encrypts only MAC frame data (user data). It does not encrypt MAC frame headers. Also, it is not used to protect MAC management messages; these always travel in the clear.
Security Associations in BPI+
BPI1 recognizes three kinds of security associations (SAs) that may exist between a CM and its CMTS.
-
A Primary SA is established during MAC registration. It is an association that remains in place between the CM and the CMTS as long as the CM retains power and is unique to the CM/CMTS pair.
-
Static SAs are preprovisioned within the CMTS. Multiple CMs may share the same static SA with a single CMTS.
-
Dynamic SAs are created and destroyed on the fly in response to the creation and termination of specific downstream traffic flows. Multiple CMs may share the same dynamic SA with a single CMTS.
At any given time, apart from the single primary SA, a modem may share several static and dynamic SAs with its CMTS, each pertaining to a particular traffic flow. Each security association is identified by a 14-bit Security Association Identifier (SAID) that is unique within the universe of SAs maintained by a single CMTS. The SAID for a modem's Primary SA is numerically equal to the value of its Primary Service ID (SID).
An SA has associated with it three parameters: traffic encryption keys, CBC initialization vectors and a ciphersuite identifier (currently limited to whether the encryption/decryption algorithm is 40-bit or 56-bit DES).
The Primary SA is used to carry all upstream traffic. Downstream flows may use any of the three types of security association. Typically, however, telephony traffic is also carried over the Primary SA, since it would defeat the purpose of encrypting the traffic if multiple CMs had access to the keying material.
Baseline Privacy Key Management (BPKM)
In most cryptographically based security systems, key management is the most complicated part of the system. Ensuring that keys are generated randomly and shared in a secure manner is usually a complex problem, and the solutions are likewise complicated. Key management in BPI1 is no exception.
Baseline Privacy Key Management (BPKM) uses X.509 certificates, the RSA public key encryption algorithm, and two-key 3DES to secure the exchange of keys between a CM and its CMTS.
BPKM uses a two-tiered approach to key management, in which computationally intensive public key cryptography is used to establish a shared secret, the Authorization Key (AK), between the devices. The Authorization Key is then used to secure the exchange of the keys used for securing traffic, which are known as Traffic Encryption Keys (TEKs). This allows the TEKs to be changed frequently without the need for expensive public key operations. Figure 3-28 shows this diagramatically.
){kind=link}
Each modem contains an X.509 certificate, emplaced at the time of manufacture. The certificate contains the modem's public key, its 48-bit address, a manufacturer ID, and a device serial number. The certificate is signed by the modem manufacturer. This allows the CMTS, when it is presented with the certificate, to authenticate the modem. The initialization process is reasonably straightforward:
Figure 3-28 Basic BPKM Mechanism
The CM sends the certificate to the CMTS, and the CMTS authenticates the CM.
The CMTS generates an Authorization Key and returns it to the CM, encrypted by the CM's public key (which was obtained from the X.509 certificate).
In addition to the Authorization Key, the CMTS identifies the SAID and the corresponding properties of the primary SA shared by the CM and the CMTS.
The CM and CMTS jointly derive a Key Encryption Key (KEK) and authentication keys from the Authorization Key.
The CM requests Traffic Encryption Keys for its traffic flows; the CMTS responds, encrypting the TEKs with the KEK.
The rest of this section discusses this exchange in more detail.
Authenticating the CM
The BPI1 initialization sequence begins when a CM sends an Authentication Information message to the CMTS. The detailed format of this message is contained in the DOCSIS specifications. For our purposes, the important thing to know is that the message contains the modem's X.509 certificate.
The CMTS does not respond to the Authentication Information message, which is purely informative. It does, however, allow the CMTS to authenticate the modem in advance of an explicit request for security information.
Immediately after sending the Authentication Information message, the CM transmits an Authorization Request. This, as its name suggests, is an explicit request to generate security parameters for communication between the modem and the CMTS. The Authorization Request message contains the following.
A CM-Identification attribute, which itself contains, at a minimum the following
The modem's manufacturer and its serial number
The modem's 48-bit address
The modem's public key
The modem's X.509 certificate
The list of ciphersuites supported by the modem
The modem's Primary SID (which was the first static SID assigned to the modem during MAC registration). The value of a cable modem's Primary SAID is always equal to the value of its Primary SID, so this implicitly generates the first SAID value for this CM at the CMTS.
If it has not already done so, the CMTS authenticates the X.509 certificate. It then returns an Authorization Reply message, containing the following.
An Authorization Key (of length 160 bits) encrypted with the modem's RSA public key as obtained from the X.509 certificate. The public key must be 1,024 bits in length.17 The AK is used to derive two message authentication keys (one each for upstream and downstream messages) and a Key Encryption Key (KEK). The algorithm used to derive these keys is described later, in Key Derivation.
A 4-bit value that acts as a sequence number to distinguish among generations of Authorization Keys
The lifetime of the Authorization Key
The SAID of the CM's Primary SA, as well as the SAIDs of any Static SAs for which the modem is authorized to obtain keying information
The Authorization Key
The Authorization Key is a 160-bit key that is encrypted by the CM's 1,024-bit public RSA key. The precise algorithm used for this encryption is the RSAES-OAEP encryption scheme described in version 2 of the PKCS#1 standard, obtainable from http://www.rsasecurity.com/rsalabs/pkcs/.
Obtaining TEKs
Each SAID in a cable modem is independent of any other SAIDs that the modem might have. Whenever a key is needed for a particular SAID, the modem sends a Key Request for that SAID to the CMTS. The purpose of a Key Request is to obtain a TEK. The TEK, as the name Traffic Encryption Key implies, is the key that is actually used to encrypt traffic flowing through this SAID. The Key Request contains the following.
A CM-Identification attribute
The value of the SAID for which the request is being made
An HMAC, allowing the CMTS to authenticate the Key Request message. The key for this HMAC is derived from the Authorization Key, using the algorithm described in Key Derivation.
The keying material for the referenced SAID is returned in a Key Reply message containing the following.
The TEK for this SAID; the key is 3DES EDE encrypted, using a two-key 3DES Key Encryption Key derived from the Authorization Key.
A CBC initialization vector
A sequence number for this key
The remaining lifetime for this key
An HMAC, which allows the CM to authenticate this message
Figure 3-29 shows this diagrammatically.
){kind=link}
Figure 3-29 Keying Messages in BPKM
So we can summarize the process as follows.
The modem authenticates itself to the CMTS and asks for an Authorization Key.
The CMTS returns the Authorization Key, encrypted by the modem's public key.
Both the modem and the CMTS derive two authentication keys and a single Key Encryption Key from the Authorization Key.
The modem requests a Traffic Encryption Key for a particular SAID.
The CMTS returns the TEK, encrypted with the KEK, along with other keying material.
The TEK is used to encrypt traffic flowing through this SAID.
Key Derivation
The various keys used in BPI1 are derived from a 160-bit Authorization Key (AK) that is generated by the CMTS and passed to the CM, encrypted by the CM's public key. Three keys are derived from AK: the KEK, used to encrypt TEKs as they are passed from the CMTS to the CM; HMAC_KEY_U, the message authentication key used in upstream Key Requests and HMAC_KEY_D, the message authentication key used in downstream Key Replies and error messages.
The keys are generated as follows.
KEK = Truncate(SHA1(K_PAD 1 AK), 128) HMAC_KEY_U = SHA1(H_PAD_U 1 AK) HMAC_KEY_D = SHA1(H_PAD_D 1 AK)
where:
TEK Encryption
The TEK that is passed in a Key Reply message is encrypted with the KEK. Traffic is encrypted using 56-bit DES, so a 56-bit TEK is necessary. The CMTS actually generates a 64-bit TEK. The least significant bit of each octet in the generated TEK is ignored, resulting in a 56-bit key suitable for encrypting the traffic.18
The mechanism used to encrypt the TEK as it is passed from CMTS to the modem is two-key EDE ECB 3DES, applied as follows.
C = Ek1[Dk2[Ek1[P]]] P = Dk1[Ek2[Dk1[C]]]
where:
Lifetime of Keying Material
In practice, a CMTS maintains two valid sets of keying material for each SAID, staggered so that the lifetime of one set expires midway through the life of the other set. It places both sets into a single Key Reply whenever a modem sends a Key Request for that SAID. This ensures that there is always at least one valid set of keying material for the SAID. Since the CM knows when the keys expire, it can schedule Key Requests appropriately.
As well as periodic Key Requests, the CM also sends periodic (but much less frequent) Authorization Requests. The CMTS generates Authorization Keys with overlapping lifetimes, so that at least one Authorization Key is always valid.
Packet Formats
BPKM messages are carried in the Management Message Payload Field of DOCSIS MAC management messages. The details of the many different kinds of messages are beyond our scope, but they are readily available in the DOCSIS documentation. The generic format of a BPKM message is shown in Figure 3-30. The meanings of the various fields are as follows.
){kind=link}
Figure 3-30 BPKM Message Format
Code—One octet. Identifies the type of the BPKM packet according to Table 3-7.
Identifier—One octet. The CM increments the Identifier field whenever it transmits a new BPKM message. When sending a response, the CMTS places the value of the Identifier field in the matching request into its response.
Length—Two octets. Gives the number of octets in the Attribute field.
Attributes—Variable length. Carries the specific request or response information as defined by the DOCSIS specifications. Attributes are TLV encoded.
Table 3-7 BPKM Message Codes
|
BPKM Code Octet |
BPKM Message Name |
MAC Management Equivalent Message Name |
|
0–3 |
Reserved |
|
|
4 |
Auth Request |
BPKM-REQ |
|
5 |
Auth Reply |
BPKM-RSP |
|
6 |
Auth Reject |
BPKM-RSP |
|
7 |
Key Request |
BPKM-REQ |
|
8 |
Key Reply |
BPKM-RSP |
|
9 |
Key Reject |
BPKM-RSP |
|
10 |
Auth Invalid |
BPKM-RSP |
|
11 |
TEK Invalid |
BPKM-RSP |
|
12 |
Authent Info |
BPKM-REQ |
|
13 |
Map Request |
BPKM-REQ |
|
14 |
Map Reply |
BPKM-RSP |
|
15 |
Map Reject |
BPKM-RSP |
|
16–255 |
Reserved |
|
The CM's X.509 Certificate
Ultimately, the security of BPI1 rests in the X.509 certificate inserted into the modem during manufacture. If a CMTS is presented with what it believes to be a valid certificate, it will proceed with BPI1 initialization. In order to authenticate the validity of a CM certificate, BPI1 utilizes the hierarchy shown in Figure 3-31 (see Chapter 2 for more about certificate hierarchies).
){kind=link}
Figure 3-31 DOCSIS Certificate Hierarchy
The CMTS is preprovisioned with the DOCSIS root RSA public key. This enables it to authenticate certificates claiming to be signed by the DOCSIS root. Manufacturer certificates are such certificates. A manufacturer certificate contains the manufacturer's RSA public key. Since it is signed by the DOCSIS root, which the CMTS can verify, then the CMTS can trust that the manufacturer's public key as handed to it by the CM is indeed correct.
The CM certificate, which contains the modem's RSA public key, is signed by the manufacturer. Since the CMTS now has the manufacturer's public key, it can validate this certificate in turn, thereby authenticating the cable modem's public key.
Once it is certain that it has the cable modem's public key, BPI1 initialization can continue with the generation of an Authorization Key on request, and the AK can be delivered securely, encrypted with the modem's public key.
BPI1 MAC Extended Header
BPI1 operates to encrypt the data PDU portion of MAC frames. It signals this by using the Extended Header (EHDR) field of the MAC header.
As we saw earlier, the Extended Header is an optional, variable length field that occurs in the MAC header, immediately following the LEN field. The BPI1 Extended Header is five octets in length, divided as in Figure 3-32.
){kind=link}
Figure 3-32 DOCSIS BPI1 Extended Header Format
- A 4-bit field that defines the direction of flow of the frame. The value may be either BPI_UP (defined to be 3) or BPI_DOWN (defined to be 4).
- A 4-bit field containing the value 4
- A 4-bit field. This field contains the number of the key that is currently in use for the Security Association ID associated with this frame, starting with zero and incrementing by one every time that the CMTS generates new keying material for this SAID. The value in the field wraps around with every nth key generation, where n mod 16 is zero.
- A 4-bit field containing the value 1
- A 1-bit field identifying whether the PDU is actually encrypted. A one indicates encryption, a zero indicates no encryption.
- A 1-bit field that matches the LSB of the KEY_SEQ field
- A 14-bit field. In the upstream, this field contains the SID of the frame; in the downstream, it contains the Security Association ID.
- A 1-octet field. In the upstream, this field contains a number of minislots that may optionally be requested for upstream bandwidth. In the downstream, the field is set to zero and is