Securely updating a Remote PHY Device (RPD)
As demonstrated during our interop event, Remote PHY Devices (RPD) are reaching maturity. Contrary to other MSO (operator) core equipment, an RPD may be installed in an untrusted part of the MSO’s network. This requires special attention from a security point of view. This blogpost explains how to update the RPD’s software in a secure way.
Remote PHY architecture
Increased bandwidth demands and fiber deployments drive the fiber nodes deeper into the field. Moving the PHY part of the CMTS (the actual modulation) closer to the customers allows the fiber to be used in a digital way (with perfect regeneration of the signal). That increases the signal-to-noise ratio (SNR) and thus the available bandwidth.
All details on the Remote PHY (R-PHY) architecture are explained in our training course called distributed CCAP architectures. This course will get you up to speed in only half a day!
R-PHY is part of the Modular Headend Architecture (MHAv2) developed by CableLabs®, the Technical Report is a good start.
Software update mechanism
The original optical nodes were simply pieces of hardware that didn’t require updates other than replacing the hardware. The new optical nodes (RPDs) contain more functionality, including software components.
As with all pieces of software, they sometimes need to be updated to fix bugs or to provide new features. For core CMTSses or equipment within the MSO’s trusted network, the operator has full control and access from the outside world is strictly limited or prohibited. Authorized staff log in to the CMTS and start the software update. No need for additional requirements.
This changes for RPDs. These are located outside the trusted network domain, so one needs to be careful with access and updating software.
The R-PHY specification shows how the software needs to be updated. The update is triggered over the Generic Control Plane (GCP) connection, this is a secure connection that links the CCAP Core to the RPD.
The RPD software image itself is also protected. The mechanism is adopted from the Secure Software Download (SSD) mechanism for DOCSIS® 3.1 Cable Modems (CMs), defined in the Security Spec and explained in a previous blog post.
The main differences with the CM upgrade procedure are:
- Only the new 3.1 Public Key Infrastructure (PKI) is supported. The legacy certificates are not supported.
- Configuration is done through GCP instead of using a config file.
- SSD is enabled by default, contrary to CM upgrade, which needs a Code Verification Certificate (CVC) in the config file.
Signing the software images
As with CMs, both Manufacturer signing only and co-signing by an operator are supported.
For the actual signing of the code image, the Excentis DOCSIS® Signing Tool is your perfect companion.
A previous blogpost on co-signing images already illustrated how to co-sign a CM image. The tool can also be used to sign and co-sign RPD images.
An example:
$ java -jar CodeSigner.jar –mode 31sign –image files/rpd_image.img \
–cvc files/rpd_manuf_cvc.der –cvcca files/cablelabs_cvc_ca.der \
–key files/rpd_manuf_privatekey.pk8 –write files/rpd_signed_image.img
The rpd_signed_image.img file can now be used to update the RPD’s firmware.
More information
CableLabs® Specifications
Training Course on distributed architectures
