13 January 2009
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:
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.
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.
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.
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.
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.
true, as shown in Figure 4, in the
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.
<Cache>tag area. You will see that the SWF file will live—the
TTLtag 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).
Having changed the server configuration, you are going to need to restart your FMS 3.5 server. Here's how:
Finally, here are a few details you need to know:
<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
falsewhen you finish this tutorial.
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:
The next article in this loose series covers basic audio streaming using the FLVPlayback component as well as ActionScript 3.0.
Tutorials & Samples