CHAPTER 8

Security for Networked A/V Systems

CONTENTS

8.0 Introduction and Scope

8.1 The Threat Matrix

8.1.1 Viruses, Worms, Trojan Horses, and Malware

8.2 Prevention Tactics

8.2.1 Developing a Security Plan for System Elements

8.2.2 The Window of Vulnerability

8.3 Prevention Technology

8.3.1 The Main Firewall

8.3.2 Intrusion Prevention Systems

8.3.3 Intrusion Detection System

8.3.4 Antivirus and Client Shell Software

8.3.5 The Virtual Private Network

8.3.6 Securing the Media Enterprise

8.4 Basics of Cryptography

8.4.1 Modern Encryption Methods

8.4.2 Keys and Key Management

8.4.3 Kerberos

8.4.4 Digital Signatures (DS)

8.5 It’s a Wrap—Some Final Words

References

8.0 INTRODUCTION AND SCOPE

Information systems security has never been more critical.¹ At the same time, protection of information systems is increasingly complex. As A/V facilities reinvent their service infrastructure to meet business demands, traditional boundaries are disappearing. The cyber security threats lurking outside those traditional boundaries are real and well documented. Security by exclusion is both more necessary and more difficult, but at the same time not sufficient. The enterprise must also practice security by inclusion to allow access to the services that field offices, customers, suppliers, and business partners are demanding.

Information security is not only a technical issue, but also a business and governance challenge that involves risk management, reporting, and accountability. Effective security requires the active engagement of executive management to assess emerging threats and to provide strong cyber security leadership. Figure 8.1 provides a good look at the three main building blocks for a secure enterprise.

FIGURE 8.1 The building blocks of security.

Concept: Cryprographic research, Inc.

This chapter provides a summary of the basics of security in light of A/V systems. Our focus centers on the process of developing a sound security plan, what the threats are, and how to protect networked A/V systems against them.

Detailed examinations of all security aspects can be found in a number of books and Web resources. This chapter is organized around the following ideas:

At one level, security is founded on the world’s most sophisticated mathematics. At another, it is about bribery, loose lips, and poor processes. A decent percentage of security breaches occur from unhappy employees who have easy access to internal networks and systems. Figure 8.2 illustrates the two extremes of system security: plotting effort versus probability of attack success. The ideal curve is solely proportional to data encryption strength. In practice, the curve is composed of a mix of human, software, and process weaknesses. Most experts agree that encryption is rarely broken these days by hackers, although there are well-known examples—the breaking of the data scrambler for the DVD being a prime example. Rather, systems are compromised by other means. Let us look into what the threats are and then counter them with a summary of prevention and detection methods. An overview of cryptography is presented later in this chapter. The RSA key in Figure 8.2 is also explained later, giving you a chance to win $200,000.

FIGURE 8.2 Security should be proportional to the effort it takes to crack it.

Concept: Cryprographic research, Inc.

8.1 THE THREAT MATRIX

Ideally, A/V equipment in mission-critical applications is 100 percent protected against all threats. Before examining how to prevent threats, let us look at the threat landscape. In general, a networked computer system threat has a life cycle. The following five-step sequence is typical of the life cycle:

The life cycle may be cut short at any step if preventative measures are effective. For example, a port probe may be detected and the foreign data denied entry. Or, an antivirus program identifies the offender and removes it before execution.

Another threat is a denial of service (DOS). The goal is not to gain unauthorized access or run foreign code, but to deny legitimate users access to a service. Attackers may flood a network with large volumes of data or deliberately consume resources. Typical of such DOS attacks is to flood a TCP port (say, for the FTP service) with requests for a connection. One example is the well-known SYN flood associated with the initial steps in setting up a TCP connection. DOS attacks may consume a large share of main CPU clock cycles, thus preventing rightful use.

8.1.1 Viruses, Worms, Trojan Horses, and Malware

Four of the biggest offenders are viruses, worms, Trojan horses, and malware. These four sometimes-confusing terms are defined next.

8.1.1.1 Virus

A virus is a program designed to infect a computer and spread via innocent human assistance. It often announces its presence to the user and may do damage to the target system’s files or steal secrets. The virus attempts to spread via email attachments typically. In most cases a human unknowingly runs the virus program, thinking it is a friendly program or file. Always beware of executing unknown source files with .exe extensions. Plus, use caution with Microsoft Office macros, ActiveX, and some Java scripts.

8.1.1.2 Worm

A worm enters a computer via a network connection and executes a downloaded program fragment—usually in data memory—without any human action. A worm is often described as a subclass of a virus, although the two are very different in how they infect a system. Worms can spread much faster than viruses by orders of magnitude. For example, the Code Red worm infected 359K networked machines in 12 hr. Simulations of worm spreading show potential rates of 7.5 to 30 K infected machines per second! To make matters worse, the spreading is exponential in growth. A typical entry point is via a TCP/IP service port. It is common for Microsoft to publish 40–50 security vulnerabilities per year for its released OS.

8.1.1.3 Trojan Horse

A Trojan horse is a program that initially looks benign but allows for backdoor, undesired actions. One example is free downloadable programs claiming to do some desired action (a drawing program) but also performing other undesired actions, such as installing pop-up advertising software. Beware of free programs!

8.1.1.4 Malware

Malicious software, or malware, is designed to hijack some or all of the user experience and turn innocent grandmothers into porn providers. It includes viruses, worms, Trojan horses, spyware, and some pop-ups. Spyware is software that tracks usage and reports it to others, such as advertisers. Usually, the tracking is concealed from the user. A pop-up is a new browser window that usually appears unrequested on the screen, brandishing ads. Particularly maddening are those termed exit pop-ups—browser windows that launch when you leave a site or close a browser window. Within a scripting language, these are called “onUnload” and “onClose” events. Undesired pop-ups may turn the browsing experience into a sleazy carnival midway, complete with flashing lights and loud music.

Because of the prevalence of Microsoft OS and derivatives, many hackers target these systems for worm access. Other operating systems are not usually targets. Although Linux and the MAC OS have vulnerabilities, these are exploited infrequently. Several organizations document virus and worm threats. The CERT Coordination Center (www.cert.org) and SANS (www.sans.org) are excellent resources for the early notification of security threats. Many IT managers subscribe to their services for early notification. If the threat is a virus, then antivirus vendors strive to find a prevention method ASAP. If the threat is a worm, then the OS provider usually offers a software patch.

Knowing the types of threats is important, but stopping them cold is more important. The next section considers prevention tactics.

8.2 PREVENTION TACTICS

Many, if not most, computer security vulnerabilities can be eliminated if the systems are properly configured against attacks. Consistency is a key factor in security. A plan is needed for all devices that trade off usability against security. It is not difficult to wall off a computer to the extent it is practically unusable—no email access, no Web access, no internal network access, and so on. However, full and unfettered access to any and all network resources breeds trouble. Finding the balance between the two extremes is a science.

Developing a security process for an organization is the most important preventative measure. Passwords, antivirus software, firewalls, and so on are of value, but a cohesive prevention deployment process applied consistently across the organization is the most important aspect of a comprehensive security solution.

Let us put the regions of attack in perspective. Figure 8.3 shows typical boundaries between networks and systems for a large deployment. Four regions are identified, A–D, each with its own security needs. Region A is a typical element—server, desktop PC, and so on. B is a walled-off A/V system requiring very high security. This could be the news production system of a TV station, for example. Region C is the company intranet. Region D is the unbounded worldwide Internet. In most cases, either region A or B is the target for access. Regions C and D are the starting points of the attack. D is the most common starting location. However, internal attacks (C attacking A) can occur maliciously but at times out of ignorance too. For example, a virus may enter a building on a laptop or USB memory stick without the carrier even knowing it.

FIGURE 8.3 Security boundaries in large systems.

There are three security boundaries for this model. Figure 8.3 outlines typical methods to secure a boundary. For example, A, B, and C are protected from D by the use of firewalls, intrusion prevention systems, and VPNs. Each prevention method is explored in the discussion to follow.

8.2.1 Developing a Security Plan for System Elements

This section outlines the questions to resolve as part of a security plan for system elements. The answer to each question should be incorporated into an overall security implementation plan. For each case ask what the implications are for RT A/V gear. Specific prevention technology is covered later. The following QA list was loosely paraphrased from information available on the CERT Web site.

Of course, there are other items needed to define the full constellation of a security solution. However, the 14 items just listed are the most common for any system. The deeper the device is located away from the Internet/email (Figure 8.3), the less likely it is to be attacked. Still, internal attacks are possible although unlikely. A security policy may not allow any Internet access on some elements. Some vendors rely on Internet access to diagnose and repair their equipment under a service contract. More on this topic in .

8.2.2 The Window of Vulnerability

Worms and viruses are quick acting. An IT manager may have only seconds to secure a device(s) against a new network-disseminated worm threat. Because an organization can react immediately, a firewall or software patch is relied on to prevent worm infections. More on firewalls in the next section. Viruses are slower acting than worms due to the need for human action to spread. It is common to get an email warning message from IT announcing something like: “Do not open any attachment named I Love You.” For viruses there is a window of vulnerability, as illustrated in Figure 8.4. Figure 8.4 also applies to worms, but the time period is much smaller.

FIGURE 8.4 The window of vulnerability.

Concept: McAfee.

The window shows four periods: one before a virus or a “worm hole” is detected and three after. The window of vulnerability is the time when devices are open to possible attack. The avert period is the time when IT sends messages to all users not to open named attachments for viruses or to patch their computers against worms. This period is sometimes called the zero-day attack time. The implication is that attacks can start on the heels of (or before) the public announcement of a vulnerability and before a protection method is available.

Once an antivirus vaccine is produced, then all vulnerable systems should be updated with it. In most corporate environments, antivirus updates occur automatically and invisibly using antivirus management applications. The longer this takes (the customer period), the longer the period of vulnerability. Within hours of detection, an antivirus vaccine is normally available. Again, virus scanners must be installed on RT A/V equipment in cooperation with the equipment provider to guarantee RT performance when scans are active or scheduled for off-hours.

For RT gear it is especially important to have confidence that any software patch will not affect performance. Should IT install the patch, hurriedly test, and deploy, hoping that the patch works, or should IT wait until more is known about its ramifications? These are difficult decisions and keep the window of vulnerability open. For worms, OS providers often notify the community of the vulnerability and then provide the patch. The delay before the patch is installed gives attackers time to exploit defenseless system elements.

8.3 PREVENTION TECHNOLOGY

In the end, it is the prevention technology that will keep out the pirates. In general, there are five main means to prevent/discover attacks over a network:

Figure 8.5 shows the overall landscape to prevent outside attacks against internal, private networks. Of course, there are other configurations, but let us use this one for the purposes of discussion.

FIGURE 8.5 Strategies for protecting business and A/V systems.

8.3.1 The Main Firewall

The main firewall is the classic method used to protect against outside intrusion. Firewalls come in many flavors from a variety of companies. Some are host based and run on desktops, servers, and so on. Microsoft’s Vista Internet connection firewall is a prime example. Others are network based, such as FireWall-1 from Check Point Software and Cisco’s PIX Firewall family. Figure 8.6 illustrates the four main functions of a generic firewall. Some firewalls have added loads of other functions, such as NAT translation, VPN, and so on, but these are auxiliary to the main purpose behind a firewall, with the possible exception of VPN.

FIGURE 8.6 Firewall filtering methods.

A firewall blocks malicious packets by using one or more of the following strategies:

Of course, the firewall should be configured by a competent IT security expert for the most effective blocking. There are several subtle settings that only a skilled expert would be aware of.

If A/V applications move data via a firewall, then attention must be given to bandwidth and other QoS needs for remote access. Does the remote user expect to transfer files at high rates? Will the transfer application be FTP? If so, it may be more practical to locate the FTP server in a third-party service center completely isolated from the enterprise network. Using off-site file transfer services allows for scalability, very high transfer rates, and complete isolation from business systems. For example, see www.yousendit.com for a free basic service.

Also, it is not uncommon to have remote user access A/V files for proxy viewing and editing. It is problematic to allow direct access even via a firewall. In this case a secure VPN connection should be forged to guarantee secure access.

8.3.2 Intrusion Prevention Systems

The IPS has a higher level of blocking than a firewall. There is much industry debate about the need for this in addition to a firewall. Most of the IPS vendors do not attempt to duplicate all firewall functionality. However, some functions are indeed duplicated, along with many functions not found in a firewall. If one is installed, a firewall must also be used, as shown in Figure 8.5. The handwriting on the wall seems to indicate that eventually the IPS will likely assume firewall functions (or the firewall will assume IPS functions) as the product category matures. The IPS protects the A/V system but not the business system in Figure 8.5 ; however, it could also protect the entire internal network.

Higher levels of IPS security include the following:

The idea that an IPS appears as a bump on the wire is interesting. Most IPS units do not have a MAC or IP address and are simply inserted into the desired key path (Ethernet link) without any configuration. Their ability to analyze data streams for attack signatures and to stop any suspect data is a powerful feature. For example, some external malevolent probes look for device TCP port buffer overflows (and then take command of a CPU), but an IPS can detect this kind of activity and abort its operation.

The power to filter streams enables the virtual software patch. What is this? In most cases, the discovery of a worm vulnerability is accompanied by the release of a software patch for a program or OS. Ideally, an enterprise IT department will immediately install the patch on every target server and desktop. In reality, there may be a long delay between the availability of a patch and its installation on all vulnerable devices. It takes time to qualify a patch and then time to distribute the patch. Then, too, for real-time A/V equipment (on-air video server) the patch should be qualified by the A/V vendor first before the end user installs it. All this amounts to the window of vulnerability being stretched into days or even months in some cases.

Enter the virtual software patch. As soon as a vulnerability is announced, the IPS vendor can update its attack signature database to include this new threat. The vendor then downloads this new attack filter into every IPS under contract for real-time updates. In a matter of hours after a worm vulnerability is discovered, an entire network of computers can be protected against the new danger. This is a powerful feature and protects devices before they have installed the latest software patch for a particular exploit. Figure 8.7 illustrates this idea. No A/V vendor testing, no enterprise testing, and virtually immediate protection. That is the power of the virtual patch. Should the enterprise still install the recommended patch? Likely, but now time is not as critical, and a methodical plan to perform updates is in order. No rushing, no errors.

FIGURE 8.7 The IPS and the virtual software patch.

As a point of illustration, the UnityOne IPS from TippingPoint Technologies is one such product that provides for virtual software patches (see www.tippingpoint.com for more information on these ideas). The IPS is a valuable product category and plays an important role in protecting mission-critical A/V gear.² Especially important is that device protection does not require the A/V vendor to qualify the suggested software patch immediately.

The IPS can become a lightning rod of blame when there are network problems. True, on occasion it can exhibit false positives if not tuned correctly. Albert Einstein once said, “Not everything that is counted counts, and not everything that counts can be counted.” Due to the complex nature of blocking threats, some false positives and false negatives will occur, so some enterprises are slow to install an IPS because it may block legitimate traffic. Then, too, if all traffic crosses through the IPS, it is a single point of failure, so a failover means is needed. Looking back 10 years, the newly introduced firewall was a punching bag when access problems occurred. Today the firewall is a necessary, noncontroversial system element. The IPS is maturing, and over time it will likely reach a point of acceptance where it becomes de rigueur as a system element.

8.3.3 Intrusion Detection System

The IDS inspects data traffic and looks for problems. When irregularities occur, they are logged with optional notification to management. The IDS does not block traffic but indicates that traffic may be harmful. It is a fire alarm, not a fire extinguisher. The IDS signals attacks explicitly addressed by other security components (such as firewalls and even IPS) and also attempts to provide notification of new attacks unforeseen by other components. Intrusion detection systems also provide forensic information that potentially allows organizations to discover the origins of an attack.

As the IPS matures, it will replace the IDS for many applications. In theory, a full-featured IPS is able to detect, report, and block threats, so investing in both technologies may be a waste of resources. Some consultants see the IDS as an essential component for sniffing at select parts of the network so it may well survive for some time. For example, when a virus or other threat is carried into the enterprise via an USB memory stick, the IDS should detect the traffic and send an alarm. Keep in mind that the IPS may not catch a threat that is released inside an organization. The demise of the IDS is a controversial conclusion, so time will be the arbiter.

In the open source world, Snort has become the de facto IDS standard (see www.snort.org for information and downloads). This Web site has lots of information about threats and how to identify them. See, too, (Beale) for the complete bible on Snort.

Intrusion detection devices are not tuned for A/V gear or applications, so there is nothing special to expect from them in this regard. They are not in series with mission-critical data flows, so their failure will not immediately affect business operations. Looking forward, it seems that the firewall and fullfeatured IPS are the future of enterprise filtering and intrusion detection.

8.3.4 Antivirus and Client Shell Software

Despite the power of the IPS, many will not block malicious virus attachments. As a result, it is good practice to keep up-to-date virus scanners on every desktop and server. Scanners are mature, and updates can occur in real time once an antivirus is produced. However, using antivirus programs on real-time A/V gear is problematic. Because most of these programs are not respectful of real-time devices and steal a good portion of CPU power to do a scan, it is prudent to schedule the scan for off-hours if possible. If the device is in service 24/7, then the A/V vendor needs to supply a solution that works in harmony with your needs. It is possible to place the scan at a low priority so as to only minimally steal CPU resources with no adverse affects on A/V performance.

The enterprise perimeter has become fluid as it passes through teleworkers, mobile employees, and contractors. Security policies should be enforced among a decentralized user base as effectively as they are on the corporate network. Employees and contractors, whether deliberately or inadvertently, are in a position to seriously compromise existing security practices. The fast-changing pace of technology, such as the widening adoption of VPN and the rise of the “zeroday exploit” requires new methods to stop threats from spreading. One means to add security is via a client shell. This is an example of a host-based IPS.

Cisco’s Security Agent, NetIntelligence’s End Point, and other products are software shells that monitor all I/O network activity and user actions on end point devices such as a PC. Some shells can be configured to only allow for selected user operations. When a firewall, antivirus, filters, application restriction, and usage monitoring of all sorts are combined, these programs offer a high level of localized protection. However, they may even be more invasive than a vanilla virus scanner in terms of affecting A/V real-time operations, so do not install one of these on critical A/V gear unless the supplying A/V vendor guarantees performance.

8.3.5 The Virtual Private Network

The heart and soul of secure remote access are bound up in the VPN. The basic idea is to encrypt the TCP/IP data packets from external users to hide them from prying eyes as they traverse the Internet. Also, the logon process for these users is secure, using time-stamped passwords and other means to make unauthorized access almost impossible. The VPN is the vehicle to secure a tunnel from the external user to the internal network. For all practical purposes, remote users are an extension of a private network.

A VPN creates a secure “tunnel” through the public network, so the protocols used to establish the connection are called tunneling protocols. Figure 8.8 shows the three most common ways to use tunnels for modern VPN implementations: L2TP with IPSec, IPSec alone, and SSL/HTTPS. The acronym soup will be explained next.

FIGURE 8.8 Using tunneling protocols to create secure VPNs.

L2TP is the Layer Two Tunneling Protocol (RFC 2661) and can run over IP/UDP and others and carry various protocols in its tunnel. It also supports authentication means for user access. IP Security (IPSec) is a method used to secure IP packets. All packet data, except for the IP address header, are encrypted for passage over unsecured networks. As a result, it is obvious that the TCP and UDP payloads are also encrypted. IPSec is a suite of protocols (see RFC 2411 for a good summary). IPSec uses the Internet Key Exchange method (IKE, RFC 2409) to obtain the encryption keys per connection. The IKE uses Diffie-Hellman (DH) Public Key exchange. DH is described later.

The Secure Sockets Layer (SSL) is used most often to secure HTTP, and the combination is called HPPTS (as seen with https://). Virtually all common Internet browsers support SSL natively, which is a big convenience for “any client” (kiosks, wireless hotspots, Internet café, etc.) secure remote access. While SSL can add security to any protocol that uses TCP, it occurs most commonly with the HTTPS access method. HTTPS serves to secure Web page access. SSL uses public key cryptography and public key certificates to verify the identity of end points. The term Transport Layer Security (TLS) has somewhat replaced SSL, but both are used to describe essentially the same functionality.

8.3.5.1 Three Secure VPN Methods

What are the differences and trade-offs among the three VPN methods as illustrated in Figure 8.8 ? The L2TP/IPSec method carries user data IP/UDP/TCP payloads by L2TP, which in turn are carried by IPSec. This is a common method for remote users who need complete secure access to a corporate network with strong authentication. Most often, specialized VPN software must be loaded on any remote machine to support this form of VPN.

For office-to-office connections, it is possible to only use IPSec, as there is no user authentication. The connections are permanent, and the tunnel provides transparent access for any IP payload.

The third method with only SSL usually supports HTTPS. This allows remote users to access HTTPS Web mail as supported by Microsoft’s Exchange Server, for example. Importantly, even though SSL is secure, it is also application based. Remote users do not have access to the entire internal network, only to the device and application (e.g., Web server) that terminates the SSL connection. As a result, SSL adds security by tying a remote user to an application and not the entire internal network.

Some SSL-based VPN solutions permit access to more than Web applications using a proxy mapping method. However, each application must be “Webified” either natively or via the proxy mapper so that it may be accessed via a remote browser. SSL/VPN falls short of offering 100 percent complete internal network access, but for most remote users this is preferred. There is currently a huge marketing battle between IPSec VPN vendors and SSL-based ones.

For A/V applications, L2TP/IPSec is a likely choice for remote proxy browsing, A/V editing, and file transfer. The remote users may have access to all the resources within the A/V system, but the IPS (remember, it is bidirectional in Figure 8.5) can limit access into the corporate network as needed. SSL/VPN providers claim equivalent performance to L2TP/IPSec, but each vendor will offer some slightly different model of operations, as the SSL/VPN is still browser based. Because SSL is TCP specific, UDP streaming applications are not supported, whereas with IPSec they are. With L2TP/IPSec, applications are browser independent.

Strictly speaking, VPN is a tunnel between end points over a network. Most references refer to VPN as secure (as our examples do), but some authors refer to VPN as a tunnel—secure or not. For example, Generic Routing Encapsulation (RFC 2784), IP-in-IP, and MPLS are tunneling protocols but are not encrypted. Often they are combined with an encryption method (such as IPSec) to create a secure VPN.

8.3.6 Securing the Media Enterprise

In any large media enterprise, there are two domains: business operations (finance, marketing, HR, traffic, planning, etc.) and media operations (ingest, master control, archive, etc.). For the most part, the media operations are considered mission critical and must be protected from any security threats that exist on the business side. This is not to say that business operations do not require security measures. However, the media operations must have the absolute highest level of security from unintentional actions or rogues originating from the business side. Imagine someone across the Internet gaining control of a TV station—shudders!

Figure 8.9 shows an example of how to protect the media operations domain. The basic idea is to insert security bridging between the two domains. The level of access into media operations depends on needs. Nothing travels between the two domains without strict security, checking, and permissions. Typically, access is granted to specific IP addresses or specific applications. Remote access may be permitted via VPN to enable vendor monitoring and maintenance of media equipment.

FIGURE 8.9 Secure bridging methods of operational areas.

Note that the business operations domain has its own security mechanisms of firewalls, IPS, and so on (not shown in Figure 8.9). The security bridging area is in addition to the already existing security measures for normal business protection.

One method that several large U.S. broadcasters use is the quarantine file server. Any file destined for the media side is first stored on the quarantine server and checked for viruses and so on. Once the file is known to be clean, it is manually or automatically transferred to the end destination. Not all media domain PCs or servers may have access to the business side and associated WAN (or Web) connectivity. If this seems draconian, then remember Andy Grove’s comment—“Only the paranoid survive.”

Next, a cornerstone of security is covered—cryptography. As mentioned earlier, total security is bound up in process and technology as per Figure 8.2, so hiding data behind mathematics is only a part of an overall way to secure the enterprise. This fascinating aspect of security is considered next.

8.4 BASICS OF CRYPTOGRAPHY

Quiet, I’ve got a secret to tell you. These words are whispered millions of times a day in a variety of networked transaction scenarios. Keeping secrets is one of the most important activities in an IT environment. No discussion of security can be complete without at least a cursory look at the basics of cryptography—the basics of keeping secrets. This section introduces four fundamental elements of secure transactions: encryption, keys, key management, and digital signatures. With the hacker’s appetite to break into every nook and cranny of networked systems, cryptographic methods are applied to transactions of all kinds.

The history of secure transmissions is as old as mankind. One of the most famous persons of antiquity to employ coding of messages to foil eavesdroppers was Julius Caesar. In The Gallic Wars, Caesar describes using a substitution cipher to deliver a military message to Cicero, whose troops needed encouragement during a particularly difficult campaign. The author of the message substituted Greek letters for Roman letters, rendering the message inexplicable to the enemy. Caesar used three of our four themes: (1) encryption—the substitution cipher method; (2) a key—the “trick” to the cipher/decipher, swap Roman letters for Greek; and (3) key management—Cicero and only Cicero should know how to decode the message. Over the course of human development, thousands of ciphers have been developed to secure messages. So let us jump ahead two millennia and peek into the state of the art of these four themes.

8.4.1 Modern Encryption Methods

There is an ocean of methods to encrypt/decrypt messages. This dialogue is limited to several of the most popular methods: DES, Triple DES, and IDEA. Figure 8.10 shows the simplest picture of a cryptosystem. Let us concentrate on the encryption/decryption methods—the keys used to uniquely code and decode the messages. For many systems, the two keys are identical. Our story has three players: sender Bob, receiver Alice, and eavesdropper Bart.

FIGURE 8.10 A basic crypto system.

The Data Encryption Standard (DES) was developed in the 1970s by IBM for the U.S. government. This was the first “data mangler” to find wide acceptance; it was free of licensing fees, simple to implement in hardware, well documented, and fast. It is a symmetrical design; i.e., the same algorithm is used to decrypt as is to encrypt. Considering the amount of data morphing that DES does, this is an amazing achievement. The basic idea is shown in Figure 8.11. A message (parsed into 64-bit chunks or blocks) enters at the left side, is permuted by the initial permutation (IP, a remapping of the input bits), and then is mangled 16 times by a combination of the all important cycle operator (CO), followed by an XOR function. At the final stage, the output permutation (OP) exactly undoes the IP operation. The CO function is a relatively involved combination of a bit permutation followed by an XOR (with an internal key as its second input) followed by yet another substitution/permutation of bits. Each cycle makes the input message more and more unrecognizable. After so much data morphing, it is nearly impossible to examine the output and thereby determine its input without knowing the key.

FIGURE 8.11 Mangling numbers: Highly simplified DES design.

The internal keys Key_1 to Key_16 are derived from the 56-bit master key. Each internal key is a different circular bit shift and permuted version of the master key. Also, the decoder is amazingly the same device with the same 56-bit master key that the encoder used but with the 16 internal keys reversed; i.e., Key_1 (decode) is Key_16 (encode) and so on. Truly, DES is an object of beauty. To learn more about CO function, do an Internet search on “DES encryption” and feed to your heart’s desire or visit http://csrc.nist.gov/publications/fips to learn more about DES in general. See also (Stallings) for a good coverage of cryptography and DES.

At first, the DES algorithm was kept a national secret, as the thought of providing a recipe to nefarious Bart was abhorrent. It was finally published, which proved a good idea, as the “hacker/cracker” community could test its muscle. In fact, it did. A prize of $10,000 was offered to crack DES by finding a particular 56-bit key value. In 1997, a worldwide user community of 14,000 PCs running a cracker program for 4 months finally broke DES. Mind you, this was 4 months to discover the value of one particular key. However, the cat was out of the bag, and the security experts needed a better algorithm than DES. Interestingly, knowing the architecture of DES was of no help. The key was discovered by brute-force testing of all (or until the key was found) key possibilities.

What was DES’s biggest sin? The master key length was too short at 56 bits. Let us assume that a 56-bit key could be discovered in 1s by a cracker. This is very optimistic, as the world record to crack DES is 22.5 hr using a massive array of PCs. For more information on how this was done, see www.distributed.net. By simple scaling, it would take 4 min to crack a 64-bit length key; 76 bits takes 12.1 days, 112 bits takes a billion years, and 256 bits takes 10⁵² years. So the trend is obvious and comforting to Bob and Alice and troubling to Bart. Clearly, Bob’s message is safe for eons and then some as the key length becomes moderately large.

8.4.1.1 Beyond DES

Since a single DES seems doomed, the crypto community tried a novel idea—triple DES. Consider a DES encryption (key1), followed by a DES decryption (key2), and then again by a DES encryption (key1 again). The overall effect is a 112-bit keyed cipher that is super secure. Not content and looking for efficiencies, two cryptographers in 1992 developed the International Data Encryption Algorithm encrypt engine. This works with a 128-length key, is twice as fast as DES methods, is more software friendly, and looks like a close cousin of DES in terms of operation. It has achieved the status of triple DES and is included in many cryptosystems in everyday use, despite the fact that it is patented and needs a license to use. Other coders in common use are the Advanced Encryption Standard and the stream cipher RC4 (which encodes a byte at a time, not a block at a time). Incidentally, these crypto methods can function in real time to process high-rate A/V data streams if needed.

8.4.2 Keys and Key Management

Let us look again at Figure 8.10. Focus on the two secret keys. They must be the same for DES or the other common symmetrical encryption/decryption engines to operate properly, but how do both sides agree on a common key? Here is one way.

Eavesdropper Bart (who is always listening) loves this type of message, as he now knows the key’s value and its lifetime. Whoopee! Imagine the living nightmare of securely administering and distributing the keys for millions of multiparty coded conversations between Bobs and Alices. Simplifying this problem eluded cryptographers until 1976 when Whitfield Diffie and Martin Hellman published their seminal paper, “New Directions in Cryptography” (DiffHel). They introduced the idea of a public key and a private key instead of using two identical secret keys, as implied in Figure 8.10. The basic idea is that different keys are used for asymmetrical encryption and decryption (DES is a symmetrical algorithm). The public key is used for encryption, and the private key is used for decryption. The first key is publicly known, and the latter is kept strictly private.

A brief survey of the concepts behind the idea is worth our time, but a full discussion of this method is beyond the scope of this book. With the assistance of Figure 8.12, we can see the essence of the public/private key method. The lower portion of the diagram is essentially the same as Figure 8.10. The upper portion shows a “secret key” exchange method using a public key and a private key. Some of the salient aspects of Figure 8.12 are as follows:

FIGURE 8.12 A hybrid method of coding using public/private keys.

Your first thought may be “This is complex with three different keys and three different crypto methods.” Think of it this way: in the big picture, this is the simplest way to solve the secret key distribution problem. One of the beautiful aspects of this method is the concept of a public key. It may seem that making a key available publicly as part of a cryptosystem is outlandish and just plain stupid. After all, why provide Bart with any hints? Despite publishing the public key, this method is extremely secure and has not been broken by any cracker.

A plaintext message is sent from Bob to Alice as follows:

Because the key exchange cryptosystem is used only for sending keys and not to encode the target plaintext message, the architectures of Pub_Enc and Priv_Dec need not be especially efficient or fast (on the order of 1,000 times slower than DES is okay), as they are used occasionally and only for short (<2,048 bits) keys. The magic of the public/private concept is embedded in the way in which the keys are created and how Pub_Enc and Priv Dec function.

8.4.2.1 The Public/Private Key Method

Diffie and Hellman invented a creative and beautiful key exchange framework. Their main thesis is the following: What function Y = Fun(P) is easy to solve in one direction but fiendishly difficult to solve in the inverse?

An example of this is the deceptively simple one-way function Y = P1 × P2, where P1 and P2 are prime numbers. Computing Y for values of P1 and P2 is easy even if the primes have hundreds of digits. For example, if P1 = 13 and P2 = 19, then Y = 247. However, if asked to find P1 and P2 given the value 247, you would need to put in some effort.

Now if the Ps are hundreds of digits long, imagine how difficult it would be to factor the resulting product if you had no hints. The current state of mathematics provides no fast methods to factor large numbers. Oh yes, there are tricks galore to speed up the factoring problem, but no quick fix methods exist. Given a factoring engine capable of ~10¹² operations per second, it would take over 1,000 years to factor a 250-digit number (Stall) and about a million years for a 350-digit number. A composite number of 600 digits is currently beyond the scope of any machine to factor in a lifetime of the universe.

Diffie and Hellman did not utilize the factoring method but rather discovered another one-way function called the discrete logarithm. Finding secure one-way functions is very challenging, and their method ranks among the truly great discoveries in cryptography. It turns out that by utilizing one-way functions, both public and private keys can be generated. Their paper inspired three other cryptographers to improve on the idea. In 1978, Ron Rivest, Adi Shamir, and Len Adleman of MIT proposed a method of public/private key generation now called the RSA algorithm. Their method proved so successful that RSA Security (www.rsasecurity.com) was formed to commercialize the concepts. The RSA algorithm relies on the inability of machines to factor 200+ digit decimal numbers. The RSA algorithm is particularly complex, yet beautiful too. The basic idea is (refer to Figure 8.12) as follows:

Bob and Alice now have the same secret key, so they can proceed to send the actual message of interest using the lower part of Figure 8.12. Many books on cryptography spend 50+ pages to describe the public key method. Obviously, many details have been omitted here for the sake of simplicity. For an enjoyable and enlightening coverage of this method, see (Singh).

In practice, many real-world systems use either the Diffie-Hellman or the RSA Public/Private key exchange method. For example, IPSec uses Diffie-Hellman key exchange and SSL uses RSA methods. Even with the wonderful invention of the public/private key technique, there is a need for trusted agencies to accept, store, and publish public keys. As you might imagine, there are all sorts of things that can go wrong unless someone manages the keys properly. An entire industry has been created to manage keys. Certificate Authorities (CAs) do the job of guaranteeing binding between the public key and the owner, thereby preventing masquerading. The Public Key Infrastructure (PKI) is a complete system for managing public keys and includes policies and procedures and digital certificates. A digital certificate is a short record that holds information about a person or organization, including any associated public key. A certificate binds a public key to its owner. For more information on CA, see, for example, www.verisign.com for practical solutions and white papers. Standard ITU-T X.509 specifies all the relevant details to implement a PKI system.

8.4.3 Kerberos

The much-used public key method is still a complex beast. As an alternative, the Kerberos (Greek spelling of the mythical three-headed dog that guards the entrance to the underworld) protocol is sometimes used. This method supplies identical private keys to Bob and Alice for their use in straightforward symmetrical DES encryption/decryption. It tends to be used at universities and within companies where a certain amount of trust can be placed in the operators. Over the raw Internet, the PKI is preferred over most private key exchange means. Still, Kerberos is widely used, and the open source code is available from MIT (RFC 1510).

The basic idea is that Kerberos uses two trusted third parties at the same time: the Kerberos server and the ticket-granting server. Bob and Alice transact with these servers to get a common secret key that they will subsequently use for exchanging their target coded information. The full transaction explanation is beyond the scope of this book (Wenstrom). Before leaving cryptography, we need to cover one more topic: digital signatures.

8.4.4 Digital Signatures (DS)

As the name suggests, a digital signature (DS) is a digital fingerprint of a data file. As with a traditional signature on a document, a digitally signed document attaches a person’s acknowledgment or approval to the document. A DS is a form of checksum (or DNA strand by analogy) that may be used to validate a target data file’s contents. Let us call a plaintext message PT and the DS of this as DS(PT). A DS is a hash function (also called a message digest) that “compresses” an entire PT no, matter how long, into a single value normally less than 256 bits. For example, the digitally represented signature of this book is a unique DS value. This value may be used to verify that an electronic file copy is indeed 100 percent identical to the digital master DS. Some of the aspects of a DS are as follows:

As with most signatures, a digital signature may be used to verify who sent a PT message. Assume that Bob sends Alice a coded PT message, but Alice wants to know for sure that Bob sent it and not someone else (authentication). An example of this is the following:

The last step is the significant phase in authenticating that Bob is who he says he is and that the received PT is the correct message. Digital signatures are used for a variety of applications, and this example is only one such instance. Message digests are well-accepted components in the big scheme of security, public key management, authentication, and the validity of messages.

In 2005 some university researchers discovered collisions for SHA-1. MD5 was shown to be vulnerable as well. This means that two different files produce the same signature. This is not good, and algorithm “fixes” are being studied. A collision is extremely rare, so for many applications, the problem is an academic issue.

The overall basics summarized in this section should provide you with sufficient understanding to plow through the minefield of cryptographic jargon. Don’t feel bad if these concepts don’t smoothly roll off your tongue; after all they are the results of hundreds of cryptographers’ efforts combined over 40 years. Fortunately, too, most applications hide the gory details from users. But it’s good to have a general knowledge of the main themes that are being employed daily in IT systems and the Internet.

Remember that cryptography is not the total solution to security. It’s really about process, not math. Encoding rules are only a small part of overall security methods.

8.5 IT’S A WRAP—SOME FINAL WORDS

Security methods will likely never become simpler than they are today. As threats increase, methods to protect against them will become increasingly more complex. This is a fact of life in the digital age. The networked requirements of A/V force security methods to account for real-time applications as never before. When deciding on security policy, factor in the real-time needs of A/V or pay the price of poor performance for applications.

REFERENCES

Beale, J., et al. (May 2004). Snort 2.1 Intrusion Detection (2nd edition). Burlington, MA: Syngress Press.

Diffie, W., & Hellman, M. (1976). New Directions in Cryptography, IEEE Transactions of Information Theory, IT 22/6.

Networking, Analysis, Collaboration (www.netapps.org), Enterprise Security Architecture: A Framework and Template for Policy Driven Security, 2000, Executive Summary.

Singh, S. (1999). The Code Book: Anchor Books ISBN-10: 0385495323.

Stallings, W. (1995). Network and Internetwork Security. Saddle River, NJ: Prentice Hall.

Wenstrom, M. (2001). Managing Cisco Network Security. San Jose, CA: Cisco Press.