Beginner's guide to security features in Flash Media Server 3.5

This article is the fourth in a loose series of beginner's tutorials. This tutorial shows you how to put the new security features of Flash Media Server 3.5 to good use. First I show you how to encrypt your videos so that users cannot intercept them off the web while they're being streamed. I then explain how to enable SWF verification so that users can't decompile and reuse your SWF files.

Here are all the articles in the series:

• Part 1: Installing Flash Media Server 3.5
• Part 2: Streaming video with Flash Media Server 3.5
• Part 3: Using ActionScript 3.0 with Flash Media Server 3.5
• Part 4: Security features in Flash Media Server 3.5
• Part 5: Streaming audio through Flash Media Server 3.5
• Part 6: Streaming live video with Flash Media Server 3.5
• Part 7: Dynamic streaming with Flash Media Server 3.5

They don't call it the "wild, wild web" for nothing. It is not uncommon, for example, for you to post a video to your site and to have it appear somewhere else in what seems like mere minutes. In fact, if there is a valid reason for hobbling the use of video on the web, it's that it is unsecure.

Let me be really clear about the purpose of this article. The approach I want to take here is not to wrap my video inside a security cordon that approximates the protection level of a head of state. Instead, I want to make it freely available—just not easily stolen.

Let me explain by way of analogy. Recently I needed to buy a mouse for my laptop. What struck me about this simple purchase was the mouse's packaging: it was encased in that hard plastic shell that requires a chain saw to open. The purpose of the packaging is to prevent theft. It takes an awfully long time to open, and the odds are really good that, if you were to attempt to open the package and swipe the mouse, there would be a security guard looking over your shoulder asking you what the heck you were doing.

Delivering your video with progressive download—that is, downloading the FLV into Adobe Flash Player using an HTTP connection—is the equivalent (in my store analogy) of simply dangling the computer mouse from its USB cord on the shelf. It is totally unsecure and relatively easy to swipe. The reason is that the FLV file is downloaded to the browser cache. It takes no effort whatsoever to move that FLV file from the cache to the desktop.

If you are a hobbyist and post videos of your children for the grandparents or shoot stuff through your cell phone, security is not a huge concern. Progressive download probably makes the most sense for you. If, on the other hand, you have paid for the content itself or paid some serious money to have it professionally produced, you probably have a reasonable need to protect that investment. This is where Flash Media Server comes in.

You see, when a video is streamed through FMS, nothing hits the browser cache. Flash Player does all the heavy lifting to translate the bits flowing into the player into the video you see in the FLVPlayback component (or custom player) on the web page. Streaming through FMS adds a major upgrade in the security cordon around the video. It's as if the retailer has chained the computer mouse to the display or moved it into a locked display case.

Note: Read the section "Delivery options for Flash video" in the Flash Video Learning Guide to find out more about the options available to you when delivering video on the web. Also check out the short video, "Delivering video on the web," in the Video Technology Center to hear more about the differences between progressive download and streaming delivery of FLV files.

Flash Media Server 3.5 has two built-in features that allow you to put that mouse back on the shelf, and not get swiped: encryption and SWF verification. This article shows you how to apply each of these security features to a streaming video.

Don't you just hate it when you're having a conversation with someone and you just know the guy leaning on the wall over there is listening in? This is quite common on the Internet, where third-party applications have been developed that listen to what's going on between the server and your client. When they detect a data stream that interests them, they grab it—without asking.

Flash Media Server 3.5 actually has data encryption built in, and here's the best thing about it: you don't need a doctorate in advanced quantum physics to use it. In fact, it is added by a simple press on your keyboard.

Here's how:

1. Download the files that are used in this example. When you unzip the download, drag the two files (Vultures.flv and Vultures.mp4) to the media folder in the vod folder. The path is C:\Program Files\Adobe\Flash Media Server 3.5\applications\vod\media.

   Note: I would like the thank William Hanna, dean of the School of Media Studies and Information Technology at the Humber Institute of Advanced Learning and Technology in Toronto, for permission to use these clips, produced by the students at the School of Media Studies at Humber.

2. Open a new Flash CS4 Professional document. When the document opens, drag a copy of the FLVPlayback component to the Stage.
3. In the Parameters tab of the Component inspector, double-click the source parameter to open the Content Path dialog box (see Figure 1).
4. Enter the following path: rtmpe://localhost/vod/Vultures
5. Click OK. The dialog box will close after Flash gets the metadata into the FLV file.
6. Save and test the movie.

The video that plays is an encrypted version of the FLV file. By adding that letter "e" into the path, you tell FMS 3.5 to add real-time encryption to the FLV file in the vod folder. The file is encrypted as it moves from the server to the client, Flash Player. Best of all, no keys are required by Flash Player to decrypt it.

Your only indication that the stream is encrypted is if you open the FMS 3.5 Administration Console. If you click View Applications and then click the Clients tab, you will see in the Protocol column that your stream is actually streaming out of the server using the RTMPE protocol (see Figure 2).

If you have been around the web for any length of time, you know how easy it is to grab a SWF file. In fact, a very common discussion around this practice is, "Hey, I have a SWF file I have grabbed. How do I decompile it to get at the source code?" I am not going to get into the morality of this discussion because there are very specific and valid cases for this practice, but, on the whole, decompiling a SWF file is not regarded as acceptable.

This raises a rather interesting question: "I have invested a lot of time and money into the development of the SWF file. How do I stop it from being decompiled?" If you use the Flash Media Server 3.5, this is extremely easy.

Here's how:

1. Create a new Flash CS4 Professional document.
2. Add an FLVPlayback component to the stage and set its source parameter to rtmpe://localhost/vod/mp4:Vultures
3. In the skin parameter, select SkinUnderPlaySeekFullscreen.swf.
4. Add a new layer and add some text to the top of the stage or draw a simple shape into this layer. This text or shape will become massively important at the end of this exercise.
5. Go ahead, test the movie. Everything works well and the text is above the video (see Figure 3).

Note: Remember, as I pointed out in a previous installment of this series, you link to MP3 and MP4 files in the vod folder by adding the media type followed by a colon and the file name, without the extension. If the file doesn't work, check to be sure that you have not added a space between the colon and the file name.

Protecting the SWF file from theft or decompiling is a really nifty feature of the Flash Media Server 3.5. The thing about this feature is, it is not enabled by default. You are going to need to make a couple of changes to enable it.

The first change is to the XML file that drives this feature. If you are not terribly comfortable with playing with application files, feel free to copy the file you'll be changing to the desktop beforehand. This way, if you make any mistakes, you can simply replace the changed file with the original on the desktop.

6. Save the file and navigate to C:\Program Files\Adobe\Flash Media Server 3.5\conf\_defaultRoot_\_defaultVHost_ and open the Application.xml document in the _defaultVHost_ folder.

   Note: I will be using Dreamweaver CS4 to display the XML. Feel free to use this application or any other text editor to make the changes.

7. Scroll down to line 726. If you don't have line numbering, simply use swf as the search term and you will be taken to this section.
8. All you need to do now is to change the word false to true, as shown in Figure 4, in the <SWFVerification enabled="false"> tag.

Don't save the file just yet. There is another aspect of this process you need to know.

You can't just merrily turn on SWF Verification and expect it to work. You also need to place a copy of the SWF file in a very specific location. If you scroll down through the XML document you will notice there is a <SWFFolder></SWFFolder> tag. If you read the commented text in front of the tag (see Figure 5), you will realize you need to create a folder—the suggested name is SWFs—and place the SWF file you will create into this folder. What will happen is, the server will first go to the folder containing the SWF file and validate that it is, indeed, the correct one.

9. If you scroll down to the next section of the XML file, you will discover that you can also specify the Flash Player version to be used. Don't play around here. The only version that can be used is Flash Player 9,0,115 or later. This feature is here in order to accommodate future versions of the Player.
10. Scroll down to the <Cache> tag area. You will see that the SWF file will live—the TTL tag actually means Time To Live—in the cache for 1440 minutes, which is 24 hours. If you think this is a tad long or you are overly paranoid, you can change the value. In fact, change the value to 5. What you have done is to say the SWF file will only live in memory for five minutes (see Figure 6).

11. Save the file and quit the application used to edit it.

Having changed the server configuration, you are going to need to restart your FMS 3.5 server. Here's how:

1. Launch the Flash Media Server Admin Console and, when it opens, click the Manage Servers button.
2. At the bottom of the servers pane are five buttons. The one in the middle, (it looks like a circular arrow; see Figure 7) is the one you need. It is the Restart server or vhost button. Click it. You will be asked if you want to restart the server. Click Restart. This will turn on SWF Verification.

3. Return to Flash CS4 and publish the Vultures movie. Open the HTML file in a browser. The video won't play. In fact, what you are supposed to see is the bars. What you are seeing (as shown in Figure 8) is exactly what happens when a SWF file can't be validated and the server denies the stream.

4. Now, to get this thing working, you need to copy and paste the SWF file from this project into the folder you pointed to when you were enabling SWFVerification in the Application.xml file. To create that folder, navigate to C:\Program Files\Adobe\Flash Media Server 3.5\applications\vod and create a new folder in the vod folder named SWFs.
5. Get yourself back to the folder containing the HTML file you published and open the HTML file in a browser. The video plays!
6. To really see how this feature rocks the house, return to the Flash project and move the object in layer 2 to another location on the stage, as shown in Figure 9. What you have just done is simulate a "burglar" swiping your SWF file, decompiling it, and otherwise playing with it.

7. Publish the file using the same name and open the HTML file in a browser. What you will see is shown in Figure 10. Essentially, FMS 3.5 has looked at the current SWF file, headed over to the SWFs folder and asked a simple question: "Does the SWF file in this folder match the SWF file that is currently playing?" The answer is a resounding "No," and the result is the denial of the connection request.

Finally, here are a few details you need to know:

• If you set the <SWFVerification enabled="true"> tag, then you have turned on this feature and all SWF files you create locally will need to be verified. If you don't think you will ever use this feature, set the value back to false when you finish this tutorial.
• If you leave the verification feature turned on, make sure that every SWF file that uses FMS 3.5 is copied to the SWFs folder. If you don't, nothing will work—and I suspect Adobe tech support is in for a few irate phone calls.

I have shown you in this article how to work locally. If these two features are critical to you, talk about them with your ISP or FVSS providers regarding what you need to do in order to keep the "burglars out of the house."

This tutorial has shown you a couple of ways to protect your content. One of them is relatively simple—RTMPE encryption of the video stream—while the other uses the new SWF verification feature of Flash Media Server 3.5. If this subject has caught your attention, here are a couple of other articles that will get you going:

• Lisa Larson-Kelley goes into greater depth around this subject in Scaling and securing streaming media applications with Flash Media Server.
• If you really need industrial strength protection, you might want to look into Flash Media Rights Management Server. Read Laurel Reitman's overview.

The next article in this loose series covers basic audio streaming using the FLVPlayback component as well as ActionScript 3.0.