Keeping (Euro)DOCSIS safe from hackers

Thanks to the power of the cloud, it’s easier than ever to break the encryption as used with DOCSIS and EuroDOCSIS. Since version 3.0 of the standard it’s also much easier for operators to counter these attacks, but despite having arrived at DOCSIS 3.1 already, not everyone already implements the DOCSIS 3.0 security. This blog post explains what the problem is, and more importantly: tells you how to protect your network.


As explained in a previous blog post on certificates and PKIs in DOCSIS 3.1, DOCSIS and EuroDOCSIS use Baseline Privacy Plus (BPI+) to encrypt all user data traffic on the hybrid fibre-coax (HFC) network between cable modem (CM) and cable modem termination system (CMTS). This is necessary because due to the nature of the shared medium that a HFC network is, it would otherwise be trivially easy to eavesdrop on your neighbours.

This “eavesdropping”, i.e. intercepting data traffic to or from other cable modems, is the attack we will be looking at in this blog post.

By the way, technically speaking BPI+ is the mechanism used since DOCSIS 1.1. In DOCSIS 1.0 there was BPI (without the “plus”) that has even more weaknesses. The “plus” adds authentication in the form of X.509 certificates. Everything that follows applies to DOCSIS 1.0 BPI as well.

DES is still in use

Before DOCSIS 3.0, BPI(+) used DES (the old Data Encryption Standard) in so-called CBC mode (Cipher Block Chaining mode) with 40-bit or 56-bit keys. The encryption keys are called TEKs for Traffic Encryption Keys and are refreshed every few hours, depending on the configuration. It’s commonly known that DES is nowadays considered “weak”, which is why DOCSIS 3.0 introduced the use of AES (Advanced Encryption Standard), the (for now) secure successor to DES. However the use of AES is optional and depends on the cable operator activating it.

It turns out that many networks today still use DES. You might be tempted to think that it’s not such a big deal with the keys changing every few hours, and that attacks on DES are possible in theory but in practice reserved for adversaries with deep pockets? Not really.

Breaking DES is easy

A security researcher for an information security consultancy firm recently wrote (and published) the software tools required to launch a brute force attack against the DES TEK keys, or in other words: to be able to sniff and decrypt the downstream traffic. Requirements: a cheap QAM demodulator (USB tuner cards exist) and some servers in the cloud — the software was written mainly for use with Amazon’s EC2 and S3 services. The QAM demodulator allows to sniff the DOCSIS downstreams and the cloud delivers the required storage and computing power.

The software tools do rely on two things that are easy to counter, however (more about that later): the ability to sniff (unencrypted) ARP traffic, and the ability to ping the public IP address of the subscriber whose data you want to capture.

The attack on DES itself is based on the use of so-called rainbow tables that speed up the brute-force cracking of the TEK keys. The researcher spent about 3 weeks time and about 2000 USD of Amazon computing power on pre-calculations of 1 terabyte of rainbow tables. Future hackers can save themselves the trouble however: the rainbow tables can now also simply be downloaded.

The software, rainbow tables and the power of the cloud today make it possible to crack the TEK keys fast enough for near-realtime cracking. Think around 20 minutes of cracking time, depending on how many parallel cloud servers you throw at it. The computation cost would then be about 22 dollarcents per TEK key. TEK keys typically remain valid for a few hours, a lifetime that can be configured on the CMTS. Valid lifetimes are between 1 second and 7 days, with a default of 12 hours. A new TEK becomes active halfway through the lifetime of its predecessor, meaning that by default you will see a new TEK key every 6 hours. Then it’s time to spend another 22 dollarcents.

Protecting against these attacks

The good news is that all mechanisms exist to counter these attacks, assuming you have deployed (Euro)DOCSIS 3.0 or newer.

Strong encryption: AES

First of all, the obvious and most important measure: don’t use DES, use AES instead. Any (Euro)DOCSIS 3.0-compliant modem or CMTS will support it. This is a CMTS configuration setting. Brute force attacks against AES are not feasible in practice today. You can also do this for the 3.0 modems in your network without impacting older 2.0 modems.

Early encryption: EAE

Second, use the Early Authentication and Encryption (EAE) mechanism as introduced in DOCSIS 3.0. Among other things this makes sure that BPI+ becomes active before the cable modem’s provisioning process is started, thus not only encrypting the cable modem’s config file (in itself also a very useful feat!) but also early downstream ARP replies towards the modem. That in turn makes it harder for the cracking tools to identify cable modems who’s encryption to try and break. EAE won’t help if the attacker already knows the public IP of the subscriber he’s targeting though.

EAE needs to be supported by and activated at the CMTS. A CMTS that fully implements (Euro)DOCSIS 3.0 will support it. Again, you can do this for the 3.0 modems in your network without impacting older 2.0 modems if you still have some.

Filter ICMP

The attack in any case relies on the ability to ping the public IP address of the target subscriber. Pings are part of the Internet Control Message Protocol (ICMP). If you filter out ICMP at the CMTS, at least from outside of your own management network, then you make these pings impossible. It’s good practice regardless of which DOCSIS version you’re running.

Another reason for restricting ICMP to only the absolutely necessary sources is that it can be used in more sophisticated attacks against either DES or even AES. Then we’re not talking about brute force attacks anymore but about so-called oracle attacks. These attacks essentially rely on sending messages to a system under attack, receiving answers back on those messages, and then deducing valuable information from those replies that eventually allows breaking the encryption. Again ICMP pings are ideal candidates for this, because in many cases they just work and the ping replies are predictable.


It’s a good time to check if you have the following security measures in place for (Euro)DOCSIS 3.0 modems and CMTSes. Of course, if you’re still on (Euro)DOCSIS 2.0, consider to upgrade first.

  • AES encryption for BPI+
  • Early Authentication and Encryption (EAE) turned on
  • Filtering of ICMP pings to modem and CMTS

Reader interactions

2 Replies to “Keeping (Euro)DOCSIS safe from hackers”

  1. Filter ICMP? You are not suggesting filtering ICMP on the public address, correct? What about ICMPv6?


  2. Hi PG, I am indeed suggesting to filter ICMP on public addresses, certainly for IPv4 and as much as possible for IPv6. You’re indeed limited to what you can filter out for ICMPv6, see e.g. RFC 4890.


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.