Home > Articles > Networking

The Cable Access Link

  • Print
  • + Share This

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.

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

  1. The CM sends the certificate to the CMTS, and the CMTS authenticates the CM.

  2. 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).

  3. 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.

  4. The CM and CMTS jointly derive a Key Encryption Key (KEK) and authentication keys from the Authorization Key.

  5. 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.

Figure 3-29 Keying Messages in BPKM

So we can summarize the process as follows.

  1. The modem authenticates itself to the CMTS and asks for an Authorization Key.

  2. The CMTS returns the Authorization Key, encrypted by the modem's public key.

  3. Both the modem and the CMTS derive two authentication keys and a single Key Encryption Key from the Authorization Key.

  4. The modem requests a Traffic Encryption Key for a particular SAID.

  5. The CMTS returns the TEK, encrypted with the KEK, along with other keying material.

  6. 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:

Truncate(x, n) means to truncate x to its left-most n bits;
x 1 y means to concatenate x and y (in that order)
SHA1(x) means to calculate the SHA-1 hash of x
K_PAD is a 512-bit string formed by repeating the value 0x53 63 times.
H_PAD_U is a 512-bit string formed by repeating the value 0x5C 63 times.
H_PAD_D is a 512-bit string formed by repeating the value 0x3A 63 times.

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:

P = plaintext 64-bit TEK
C = ciphertext 64-bit TEK
k1 = 64 leftmost bits of KEK
k2 = 64 rightmost bits of KEK
E[M] = 56-bit DES encryption of M in ECB mode
D[M´] = 56-bit DES decryption of M´ in ECB mode

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.

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.

  • 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

     


  • 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.

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).

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.

Figure 3-32 DOCSIS BPI1 Extended Header Format

Type
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).

LEN
A 4-bit field containing the value 4

KEY_SEQ
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.

Version
A 4-bit field containing the value 1

ENABLE
A 1-bit field identifying whether the PDU is actually encrypted. A one indicates encryption, a zero indicates no encryption.

TOGGLE
A 1-bit field that matches the LSB of the KEY_SEQ field

SID/SAID
A 14-bit field. In the upstream, this field contains the SID of the frame; in the downstream, it contains the Security Association ID.

REQUEST/Reserved
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
  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020