PESA: Protecting Mission Critical Video & Audio

Scott Barella:
PESA is a 50-year-old company based in Huntsville, Alabama. We mainly design and build secure video distribution systems. That’s what the military calls the broadcast products we build that are traditionally known as routers and other ancillary equipment. We mainly end up in command and control, or C2 for short, and video teleconferencing pieces, all the pieces that make up a mission that’s extremely important to both our DOD customers and to our intelligence community.

But we also span a lot of other things, like education, corporate, medical, and even rocket launches. Our friends at NASA have been kind enough to show us the way in terms of how they use our products, very different from broadcast.

About 10 to 12 years ago, PESA made a conscious move out of broadcast as its primary focus, and chose to focus more on the government and other ancillary markets. But above all, we wanted to make sure that whatever we offered them could, in fact, be secure.

If you’ve watched the Olympics, you’ve seen our equipment. We’ve been a part of the Summer and Winter Games since 1988 to the most recent ones in some fashion or flavor, maybe not primary, but ancillary, as well as some other important events that have been broadcast. And our routers live on in many broadcast facilities, as well as trucks and numerous broadcast carriers. We like to think of ourselves as a complete end-to-end system.

We offer a very secure chain of making sure that we’ve analyzed the situation and that we’ve designed it to meet the needs and the requirements that our military and mission critical people are wanting us to do. And then we implement these pieces and parts to get a complete end-to-end turnkey solution to the table.

We believe, of all things, in the value of a secure nation, and that goes in hand with all those certifications that we’re required to complete as a part of this, being able to offer products to these kinds of government institutions. Securing and distributing this kind of information, video information in particular, is paramount to that global need.

Our Blade System is based on the openGear platform, at least our SDI solutions are. We’ve been a member of the openGear group for many, many moons. Our main claim to fame, obviously, is the PESA Blade System, the PBS. This is the same OG3 and OGX type frames that all of you know and have come to use over the years, because you can have so much flexibility in terms of adding other items to the package.

We make a number of H.264 encoders and decoders. These are dual encoders and dual decoders, hence the 2 and 2 package name. We also make a 1RU box, and that is a 58 that does a little bit more in terms of density. But as far as getting all those encoders and so forth inside of a common frame, the PBS system does it very well.

The next piece that we’ve used, traditionally, in these C2 environments is called the HDMI transmit/receive, or HTR for short. We have that into a more or less unsecured application, and so we don’t need that. It’s in our Vidblox lineup. The newer one that we’ve just added is the Secura SDI HTR. This offers a bit of scrambling to the SDI payload, so that people who might wander across an SDI stream, it won’t be able to be decoded unless you have the proper decoder from the opposite encoder for these boxes.

We offer a number of other different pieces that we market. Our good friends at Cobalt have helped us with some multiview products and some distribution amplifiers, both reclock and non-reclock type of applications, for those systems where we need additional cards and so forth. So we lean on them quite a bit for the bulk of our other offerings, besides the stuff that we mainly focus on for our military folks.

The idea that we’ve had from nearly the beginning of our router days was to offer a configuration suite called Cattrax. A good number of our products are named after big cats, so it made sense to name this product Cattrax. The idea here is that you have a common windows application that can address the configuration and setting up of not only routers, but all of these Vidblox components, so that we can set aspect ratios, SMPTE formats, field rates, etc. Those become extremely important in an environment where you want to have lockdown control of this.

One version of this, of our Cattrax product, is called Cattrax-J. Many years ago this was the Joint Interoperability Test Command Center-approved and -certified, and so we call it the J for JITC. And that’s an approved version that we use for customers that are insisting on a fairly confidential login and protection of the configuration once it’s been set up.

The openGear C22, our XSTREAM product, has been around for several years. It supports a number of very active protocols, including RTP. This has an HDMI 1080p input, not quite ready for 4K in this sense, but it does provide that good streaming, both unicast and multicast variance. And it features a number of cards, single 2RU hosts, and available as a stand-alone in a box where, in some applications, we don’t have the room for either a frame or we have to go outboard. So we offer the product in two flavors, one for openGear, and one for a stand-alone.

The concept is fairly straightforward: The inputs are delivered to a router, and the router sends those pieces and parts over to the inputs of the encoder. The IP output feeds the network. The output is decoded, and then sent back into a disparate router on the other end of things, typically. This isn’t always how we use it, but it is an easy example to illustrate the connection between, for example, two large routers. One of these configurations we use for a NASA project, so this was extremely well-received in terms of how it works for them.

The Multiviewer Blade piece is also used in military environments where they want to show unclassified information on a common wall of video. Our folks at Cobalt help us with this one, but we’ve made this especially suitable for these command and control rooms where not all of the pieces and parts that would be used in broadcast are displayed. Rather, the things that are important to a mission or a particular event that they’re interested in are displayed on various screens throughout the C2 environment. The blade offers both a 12G, 3G, and a number of other ones, but it has a number of things, and up to 18 discrete images for picture-in-picture images. So this helps us aggregate those pieces, and it all also offers us HDMI 2.0 inputs and outputs.

The HTR, the HDMI transmit-and-receive Secura piece, as well as the common Vidblox one, the key piece here is that we have a box or a card that can scramble the SDI input. We used a patent-pending algorithm in this. It isn’t so much high-security, like an AES or a crypto version of this, but in SDI you can’t really do that in this format. So we created something that we knew the military could base on eight different levels. And in that process, we are able to separate, for example, top secret and secret, or classified, unclassified, or any number of different security levels, where we fan out different videos to users that are authorized to see certain pieces of the mission or certain pieces of the operation that are critical for the success of the overall mission.

We can segregate the audio and video from that flow, much like you can do in breakaway audio and video. It’s very flexible. And one of the pieces that got us into the security part of the military and government was the HDCP protection. A lot of our users needed to make sure that was intact before they could actually purchase. We offer that not just for coax and fiber connections; we can actually mix and match depending on the overall configuration.

Here is sort of a use case of how that works: we take various HDMI sources, we pick on some PCs that have critical video for the mission, we take them, we can move them into the router, out of the router. We can move that to pieces and parts of the output, and then display that back again in HDMI. In the Secura version, the pieces that connect the portions of the video to the router are secured and protected, so that only those that are in that certain level that have been coded that way are able to decode it.

We’ve also been invited into a number of key medical facilities, mainly in operating rooms where video is extremely important, where it’s real-time video. Also classrooms and sporting venues in terms of that, plus financial and even congressional pieces and parts throughout, not only state capitols or state governments, but also federal governments as well. In fact, a lot of our video that you see on the press briefings for the coronavirus updates are done through our router at the White House.

One of the big risks that’s of concern to everyone, especially at places where you have a common video open to the public, is the risk of being compromised — video appears that you don’t want to appear. I love this slide because it reminds me of the days of Max Headroom. Maybe many of you don’t know who that guy is, especially if you’re the younger sort, but us older guys and gals will remember old Max here. We wouldn’t want something like that to appear, for example, in the stadium. That’s why Secura has been the thrust behind making sure that video, sensitive video, or even common video that we want is displayed in the proper sequence and manner.

With that come a number of hurdles that you would expect to have a certain grade or a certain kind of checkmark box, and we’re expected to have certifications behind our products that the government will insist on. With that, sometimes, comes encryption. If it’s IP, if it’s SDI, obviously it’s not, it’s more of a piece that ensures that the control of it is. We have bulletproof products that have withstood years of experience, and that’s why we’re in these environments. We still are, and we are moving and transitioning to more of an IP environment. And that begets us to how we’re moving these into these C2 environments. I thought I’d give you a peek into how we use them. Most of our equipment is located in a secured server room, which you’ll see in the bottom left of the slide here. Here, we have both a Secura HTR and regular Vidblox HTR, along with multiviewers and other OG products, as well as stand-alone pieces that didn’t necessarily fit or didn’t want to be encumbered by that.

We moved them out of the server room onto the floor and onto the common wall, so that once an item has been marked for clearance to be seen by all the members in the room, it can appear on the video wall. That requires a little bit of configuration, and that’s where our Cattrax and the other configuration pieces help address that, so that the administrators of the system, as they use it from a day-to-day or week-to-week basis, can change those things and make sure that the authorized stations remain that way.

Security is our key mantra these days, and we’ve really focused on this, especially when we started to move our products toward the IP side of the coin. So for security, we’ve developed not only the Secura HTR for SDI, but we’ve also moved on to both the Secura IP, the Secura KVM software-defined networking, and a media management control system that is all suited within a kind of a FIPS level grade that we can move secure information to and from certain places to other places that of course are authorized.

With that comes a lot of scrutiny, because the second we take a common video format and we make it available on IP, the scrutiny comes up and folks want to make sure that it doesn’t get opened or viewed by people who are not authorized to see it. So the main focus for this presentation is centered around the HTR, which was our mid-level security product. It’s kind of where we got started with the whole idea. It goes back to the days of when people asked us how we dealt with HDCP, and it kind of made it to the next level and the next level. As we move on through time, we were actually a part of the original Video Distribution System, the VDS, that happened as a part of the Department of Defense Information Network and their approved product list.

This happened to be, in section nine, where we co-authored this spec. As we move forward into the next generation for IP, we’ll be offering the next generation pieces, or at least helping with it. There’s a lot of pieces and parts to the VDS that are still very entrusted with us, and we take that responsibility extremely seriously. We want to make sure that these are properly protected. That comes into what they call the FIPS crypto standards.

This is a segment of certifications and credentials that NIST, the National Institute of Standards and Technologies, authors, specifically 140-2. In it we have a number of crypto algorithms that have been blessed and been tested by the NIST agencies. In it, with respect to our products, we’re focused on key exchange, trusted certs, and signatures for both dynamic and static use. We haven’t really hit common criteria yet. That’s a nigh up certification for the U.S. This mainly centers around intelligence organizations. We don’t have a lot of footprint into that yet, but we thought we’d start with the places we’re actively involved with right now. So that takes us into those two main ones, the DoDIN-APL and the FIPS.

The A/V over IP is what we’ve been working on over these past several months and years. The idea is fairly basic. We take an HDMI baseband signal. We lightly compress it using J2K. We encrypt it with AES 256. We move it across the IP fabric. Out of the IP fabric, we decode it and we unencrypt it, and we put it on properly authorized displays. That’s essentially it in a nutshell.

We borrowed this from some work in the SMPTE ST 2110 standard committee that I participated in over the past three and a half years. This one gave us the launching ground for both our video and audio services that are multicast. We just took one extra step and encrypted them using FIPs encryption. Those are both unidirectional streams, flows, and they’re multicast, so I can hook up one to many. That gives us the ability to break away the video, break away the audio. But in addition to this, we did the encryption using an SSL technology for USB.

This is unicast as you might expect, it’s not multicast, but this guy allows us the ability to secure critical HIB interfaces that a lot of our people in the C2 environments need. Not all of it, obviously, but when it does, we can have the USB component to the structure of how we would architect flows in and out of these environments.

The concept is fairly straightforward. We have a number of transmitters and a number of receivers. The blue ones are transmitters, and the red ones are receivers. I can hook up any blue to any red, or I can hook all the reds up to one blue, for example. That’s the beauty of multicast, so you have a fair amount of flexibility in here. Imagine one other layer where you would actually divide these into security levels so that we can divide them up.

Here, I show you a kind of a common area where we have just two security levels. They’re shown at the very top using VDI technology. The thin clients are shown in black and red. They’re taken to our boxes where they are encrypted and moved through IP fabric. We take them out of the fabric and move them to the code. We’re at the floor level, we can see blacks and reds appearing where they’re supposed to be. Maybe the next day it’s opposite, so the blacks to the left will be reds. The reds that you’re seeing in the bottom right, or the bottom corner there, would be black the next day.

The example systems that we’re working on, a traditional system that we use in a common silicon matrix, where we take, for instance, our openGear products and move them from a position of one client to the next. We use a traditional, very traditional, routing core where we take HDMI, convert it to SDI and move it around. But we do have a limitation. It is protected, yes, but we have a certain point where we have to base some SDI rules. We have to select some common resolutions and frame rates that are suitable and more broadcast-esque. They are commonly used in the computer side of things, but it is a limitation, nonetheless.

And in the IP environment, we don’t have that. We can go all the way from HDMI 2, all the way down to standard-def, move them across fabric, and I don’t have to worry about having the SDI cordoned off into certain chunks where I have 720p’s, 1080p’s, and say 4K. I can actually move them all in one single chunk. But in this example, I can encrypt each of those on certain levels, and do that with a FIPS certification. But it’s important to note that I’m actually encrypting the video and the audio, not just the control of it, like a lot of vendors will do. In our environments, they insist on having the video and the audio encrypted.

In a larger system where I’m using leaf and spine pieces, this breaks out into a little bit larger array. We want to secure the medium, and we want to enable the following. We want to be able to deliver timely data and images for lifesaving decisions. In this case, we’re showing HIPAA security. Not only will the military folks need this, but obviously patient security is extremely important in this day and age. We want to be able to make sure that doctors are authorized to see what they’re supposed to see, and others who are not authorized don’t see it.

So that wraps up my presentation for the day. I hope you found it interesting. It’s a little bit different take from, say, the typical broadcast bent, but at its heart, it’s pretty well founded in some of the stuff that we’ve done for these past 30 or 40 years.

Sarah:
There was a question about the HDMI on the support for the HTR, does it support anything else such as DisplayPort or DVI?

Scott:
Yeah. We have to adapt those technologies for a DisplayPort, but on our normal HTR product, for some of the lower resolutions, 1080p and lower for example, it does support those pieces. On our newer ones, the more common formats are HDMI 2, and it turns out that it’s just a smidgen more flexible. So we opted to go for that one first, since most of our DOD customers are using HDMI 2.

Sarah:
You mentioned the levels that it supports in Secura with the HTR. How many levels does it support?

Scott:
Well, the HDR side of things will support as many as eight levels. We haven’t really come across a scenario where people have needed more than eight. Most of the time it ends up as two or three. And most of the time I would say that, especially with most of our DOD, it’s unclass and class. There is an upper class, sometimes, that dictates a third tier. It’s set up such that the upper tiers can see lower tiers, but lower tiers can’t see upper tiers. Hope that makes sense. For example, if I sent video to an unclass user, it would make at least some sense that a classified guy could see the unclassified information, but not vice versa.

In other words, the classified information is protected in the room for those that are not authorized to see it. In that sense, we can kind of pick and choose across state levels who sees what, or who’s authorized to see the lower levels. In the case of where we’ve had some activity where certain video is shared with allied forces or so forth, and we need to pick and choose which part of classified we might share, or which part of unclassified we might not share, and that allows for yet another tier of users that have been cherry-picked out of those two basic categories. It allows a little bit more flexibility in the broader scheme of things with respect to security levels.

Cindy:
What do folks do if they want a demo, or a POC, how does that work?

Sarah:
We just opened our demo room that we can do via Zoom. You can set up an appointment either by sending an email to info@PESA.com or by contacting Scott directly to can set up a Zoom. It’s a discovery room, it’s a Zoom room, so you can see the demo taking place. And not just seeing the screens that are there, but you can see the person giving the demo. There’s a whiteboard. It’s very interactive, and it’s a lot of fun, so we would love to have you sign up for one of those. We have a lot of neat things to share.

Leave a Reply

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