Securing the software

The DOCSIS specifications define how cable modems must behave. If a cable modem has been tested against these specifications (certified), you can be sure it will behave correctly and securely. Ideally, that certified software is installed at production time and is never changed.

The need for bug fixes and new features necessitate the ability to remotely install new software onto already deployed modems. This ability is (and has been) an attractive target to tamper with a cable modem’s software.

DOCSIS protects the software download process by adding a digital signature (Code Verification Signature or CVS) to the code image. This does not guarantee that the new software will work correctly (that software might not be certified), but it can guarantee that a trusted manufacturer and not some hacker created the software.

The private key used to create this signature is linked with a special certificate, the Code Verification Certificate (CVC). This CVC is signed by the same root certificate as is used to create the cable modem certificates. Check this previous blog post for details on certificates and the public key infrastructures (PKI) that are used in DOCSIS.

The root certificate is pre-installed in each modem. Using that root certificate, the modem verifies the CVC (included with the image), then verifies the signature on the image and only after those checks pass upgrades its software.

Vendor and operator signed

Adding a manufacturer’s signature to a code file assures that a trusted manufacturer has signed the new software.

Sometimes, an operator wants to have more control over which software versions are installed on its network (as mentioned, the new software versions might not be certified). This can be done by having the operator add another signature to the code file. The operator then co-signs the image. To do so, the operator uses a Co-signer CVC signed by the same root certificate.

In this case, the modem verifies both CVCs and both signatures before installing the new software.

For details on co-signing and how to (co-)sign, see the blog post Using the Excentis DOCSIS Signing Tool to co-sign software images.

Enabling SSD (legacy PKI)

By default, software downloads are disabled on a cable modem. SSD is enabled by adding a special TLV into the config file containing the CVC used for the code signing. Two TLVs are defined: the Manufacturer CVC TLV (TLV 32) and the Co-signer CVC TLV (TLV 33).

/* TLV 32 : 0x308202EC3082... */
Manufacturer Code Verification Certificate:308202EC3082...
Manufacturer Code Verification Certificate:03131D436F64...
Manufacturer Code Verification Certificate:BA2589EDDD92...
/* TLV 33 : 0x308203BC3082... */
Co-signer Code Verification Certificate:308203BC3082...
Co-signer Code Verification Certificate:0403131C7443...
Co-signer Code Verification Certificate:7517DF7F379D...

For more information on how to create a config file, there’s a blog post on that.

There are 4 combination options of CVC TLVs in the cable modem’s config file. The following table illustrates the implications on the code file signature requirements:

  • No CVC TLVs present: software download is disabled
  • Manufacturer CVC (M-CVC) TLV present: software download is enabled, manufacturer signature (M-sig) is required, Co-signer signature (Co-sig) is forbidden
  • Manufacturer CVC and Co-signer CVC (Co-CVC) TLVs present: software download is enabled, manufacturer and Co-signer signatures are required
  • Only Co-signer CVC TLV present: software download is enabled, manufacturer (!) and Co-signer signature is required

Note that in the latter case, the manufacturer CVC is not present in the config file, but a manufacturer signature is required. This is possible, since the CVC is included in the code image anyway. Adding only the Co-signer CVC is a convenient way for an operator to enable SSD for modems of different manufacturers using the same config file.

SSD PKI for DOCSIS 3.1

In DOCSIS 3.1, the PKI that is used to create the Cable Modem certificates is also used for the SSD procedure. Apart from using a different root certificate, there’s another important difference: the CVCs are no longer signed directly by the root certificate, but by an intermediate CableLabs CVC CA.

In order to enable SSD in DOCSIS 3.1, a chain of certificates (containing the CableLabs CVC CA and Manufacturer or Co-signer CVC) needs to be added to the config file instead of only the Manufacturer and/or Co-signer CVC. To do this, new TLVs (TLV 81 and 82) were defined:

/* TLV 81 : 0x308203863082... */
Manufacturer CVC Chain:308203863082...
Manufacturer CVC Chain:312830260603...
Manufacturer CVC Chain:9DD9DCC27940...
Manufacturer CVC Chain:6D7331283026...
...
/* TLV 82 : 0x308203863082... */
Co-signer CVC Chain:308203863082...
Co-signer CVC Chain:312830260603...
Co-signer CVC Chain:9DD9DCC27940...
Co-signer CVC Chain:656D73312830...
...

These new TLVs are already supported in Excentis’ DOCSIS Config File Editor.

The CVC Chains are verified by the new PKI root certificate that is pre-installed in the DOCSIS 3.1 modem.

A matrix of possibilities

Next to these new PKI CVC-chains, the legacy method (using CVCs from the legacy PKI) needs to be supported as well by a DOCSIS 3.1 modem. This opens up a whole matrix of possibilities with CVCs or CVC-chains in the config file and different code signatures. The table below gives an overview:

Legend:

  • M-CVC: config file contains a Manufacturer CVC (TLV 32)
  • Co-CVC: config file contains a Cosigner CVC (TLV 33)
  • M-chain: config file contains a Manufacturer CVC-chain (TLV 81)
  • Co-chain: config file contains a Cosigner CVC-chain (TLV 82)
  • M-sig: software image contains a valid Manufacturer CVC based signature
  • Co-sig: software image contains a valid Cosigner CVC based signature
  • M-chain-sig: software image contains a valid Manufacturer CVC-chain based signature
  • Co-chain-sig: software image contains a valid Cosigner CVC-chain based signature

To summarize, following rules apply:

  1. At least one CVC or CVC-chain needs to be present in the config file to enable SSD
  2. If any CVC-chain is present in the config file, all signatures must use the new PKI, ignoring legacy CVCs in the config file; otherwise the legacy PKI is used for all signatures
  3. A software image always needs a manufacturer or manufacturer chain signature, depending on the PKI used (as determined in rule 2)
  4. If a Co-signer CVC or CVC-chain is present in the config file (excluding those ignored in rule 2), the Co-signer signature needs to be present

Note that this approach (rule 2 in particular) has some implications for an operator wishing to co-sign the images: there’s no single config file that can be used for all types of modems. If the operator would add a Co-signer CVC-chain to the config file, images from DOCSIS 3.1 modem manufacturers that still use the legacy SSD PKI would be rejected! And if the operator has no Co-signer CVC-chain, it cannot co-sign images that are already signed by a manufacturer chain.

Two obvious alternatives for an operator wanting to co-sign images in a mixed environment:

  • operator has a Co-signer CVC-chain: add Co-signer CVC and CVC-chain to the config file. Co-sign DOCSIS 3.0 images with the Co-signer CVC (DOCSIS 3.0 modems ignore TLV 82) and co-sign DOCSIS 3.1 images (already signed with Manufacturer CVC-chain) with Co-signer CVC-chain.
  • operator doesn’t have a Co-signer CVC-chain: add Co-signer CVC to the config file. Request vendor to sign its DOCSIS 3.1 software images with the legacy Manufacturer CVC, co-sign all images with the Co-signer CVC.

More details on the software download requirements (like time constraints or updating CVCs) can be found in the security specification.

More information

For learning more on DOCSIS 3.1: among other courses, we have a 2-day training course “DOCSIS 3.1” that takes an in-depth look at the changes introduced by DOCSIS 3.1.