IP Security For Broadcasters: Part 2 - The Problem To Be Solved

By assuming that IP must be made secure, we run the risk of missing a more fundamental question that is often overlooked: why is IP so insecure?

All 12 articles in this series are available in our free 82 page eBook ‘IP Security For Broadcasters’ – download it HERE.

Articles in this series:

Broadcasters have been relatively lucky as we have always worked in a closed system. Not just the network and infrastructure, but the whole ecosystem too. The whole culture of broadcasting was limited to a relatively small group and specialist knowledge was needed to even view a video tape.

We worked with transport streams such as PAL, NTSC, SDI and AES, that needed specialist equipment to decode and decipher them. Video tape needed a massive investment in equipment to play and view the material; copying it onto VHS or similar domestic formats was not as easy as the layperson might think it should be. And it was easy to see if somebody was breaking into your network as they had a pair of wire cutters in their hands.

There was a much greater level of trust. We would quite happily send high-value media across telco networks or a satellite feed to other broadcasters. And even when a stream needed to be encrypted, it could easily be done by using point-to-point encryption systems with smart cards to enable specific decoders.

Flexible Open Systems
IP has brought a system of open connectivity to the world. Again, this isn’t just about the infrastructure, but also the whole ecosystem. When IP was first developed back in the 1970s and 1980s, it was designed to be an unreliable delivery system that does not guarantee the delivery of a datagram to the destination. Although this may seem like an oversight in its design, and possibly even an error, it actually turns out to be one of its greatest strengths.

By not burdening the IP protocol with guaranteed delivery it has become incredibly flexible in terms of its ability to hop between different transport stream technologies without intervention. An IP datagram, with the correct interface, can easily switch between ethernet and WiFi or HDLC. The ethernet, WiFi and HDLC frames encapsulating the IP datagram will change, but the actual IP datagram does not change. In other words, when switching between layer-2 transport streams, nothing in the IP header or payload needs to be amended.

Purists may suggest that the TTL (Time to Live) field being decremented is a transport stream dependency, however, the TTL is a feature that is independent of the transport stream and is used to stop the possibility of an IP datagram getting stuck in an endless network routing loop.

The openness of the IP header makes the international routing of IP packets possible. If the header was encrypted then it would be almost impossible to route packets between networks, especially if they were not linked within the same broadcaster. The open IP header, combined with protocols such as BGP (Border Gateway Protocol) make the internet possible. 

Figure 1 – when a laptop sends an IP packet to the server the IP packet is first encapsulated in a WiFi frame, the layer-2 switch has already ascertained that the frame is being sent to the server and will substitute the WiFi frame for the Ethernet frame. Critically, the IP packet does not change.

Figure 1 – when a laptop sends an IP packet to the server the IP packet is first encapsulated in a WiFi frame, the layer-2 switch has already ascertained that the frame is being sent to the server and will substitute the WiFi frame for the Ethernet frame. Critically, the IP packet does not change.

IP payloads can and are encrypted, but layer-3 routers and layer-2 switches can happily transfer packets and frames based on the header contents only. The fact that the payload is encrypted has no relevance to them.

Unfortunately, the open IP header means that anybody with access to the network also has access to the IP packets. And if the payload is in the clear, that is, not encrypted, then a hostile actor has the potential to cause havoc in a network. Packets can be intercepted, their contents monitored, decoded, and changed.

Intercepting IP Packets
Once a packet stream has been intercepted, it’s relatively easy to use readily available tools such as Wireshark to receive the streams and decode the data. From here, it’s a trivial job to change the packet payload and replace the original packet. Anybody with even a basic understanding of C or Python could write code to achieve this and is in effect how man-in-the-middle attacks operate. This is one of the reasons HTTPS (Hyper Text Transfer Protocol Secure) was developed.

In HTTPS the server and host exchange SSL (Secure Socket Layer) keys that are used to encrypt the data in the IP packet payload. Therefore, anybody intercepting the packet will be able to decode the header but not the encrypted payload data.

It turns out that IP’s greatest strength is potentially its greatest weakness. But this is what IP security is all about. IP security is recognizing that we are working in an open environment where we assume the packets can be intercepted and changed. IP security is stopping unauthorized access to the network and hence the datagrams, as well as stopping anybody changing the contents if this isn’t feasible.

One type of network where we assume that packets can be recorded and changed is WiFi. By definition, the data frames are being broadcast all around us and anybody within a reasonable distance to the router can see the WiFi streams. A host of WiFi sniffers are easily available that show this, even for cell phones. Therefore, access to the WiFi network is heavily restricted and a great deal of work has gone into stopping hostile actors intercepting and changing the packet data. In the extreme they may be able to see the traffic if it isn’t encoded, but they won’t be able to change it as they don’t have access to the network.

Another area of security concern is that of vulnerabilities. When we speak of vulnerabilities, we’re usually referring to operating systems running on computers, servers, and cell phones etc. Any unethical hacker will be aware of vulnerabilities in operating systems and will work to exploit them. Memory buffer overflows continue to be a source of vulnerability leading to operating system providers and programming language designers continuously working to remove these vulnerabilities.

Security and efficiency are often traded as the more secure a system becomes, then the less efficient are the execution speeds. An example of this is a software functions return-address monitor. The monitor reads the return-address of a function when it is being executed to check for any changes as a change in the return address often indicates malicious or suspicious behavior. But this level of monitoring often incurs a high level of efficiency overhead.

Although high level languages such as Python, PHP, Java, and Perl often catch buffer overrun attacks and will cause runtime exceptions to halt execution, there are no absolute guarantees as these languages often have low level languages such as C at their core and many of the buffer overflow errors are a result of badly written C libraries, or incorrect assumptions about the environment they are operating in.

Security Flexibility Trade Off
IP is one of the most important advances in broadcast television. But a trade-off between security and flexibility was made during its inception and we must be aware of this when building our IP systems. Also, software vulnerabilities continue to manifest themselves as operating systems and programming languages improve. As vendors and designers become aware of them, they are fixed quickly resulting in new version releases of operating systems and programming languages. Another reason to constantly keep servers and workstations up to date with the latest software releases.

Part of a series supported by

You might also like...

Audio For Broadcast: Cloud Based Audio

With several industry leading audio vendors demonstrating milestone product releases based on new technology at the 2024 NAB Show, the evolution of cloud-based audio took a significant step forward. In light of these developments the article below replaces previously published content…

Future Technologies: New Hardware Paradigms

As we continue our series of articles considering technologies of the near future and how they might transform how we think about broadcast, we consider the potential processing paradigm shift offered by GPU based processing.

Standards: Part 10 - Embedding And Multiplexing Streams

Audio visual content is constructed with several different media types. Simplest of all would be a single video and audio stream synchronized together. Additional complexity is commonplace. This requires careful synchronization with accurate timing control.

Designing IP Broadcast Systems: Why Can’t We Just Plug And Play?

Plug and play would be an ideal solution for IP broadcast workflows, however, this concept is not as straightforward as it may first seem.

Future Technologies: Private 5G Vs Managed RF

We continue our series considering technologies of the near future and how they might transform how we think about broadcast, with whether building your own private 5G network could be an excellent replacement for managed RF.