| home / multimedia / video / a href="index.html">1 |   [previous] |
|
|
|
The technology behind public-key encryption involves hard math problems. By using really large numbers, a variety of mathematical problems or functions would take computers years to solve. The keys provide those large numbers, and then a particular asymmetric encryption system uses a particular hard math problem. One example is large prime numbers; the algorithm generates a pair of large prime numbers (numbers divisible by only themselves and the number 1), which are then factored together. You then use this pair of numbers to generate the private and public keys.
There are many "hard problems" to choose from--for example, another approach involves the mathematics of elliptical curves (ovals). In any event, each of these mathematical functions scrambles the message, using the large keys, and the only way to get the message is to guess the key. To guess the key requires solving the hard problem, and the hard problem is designed to take a fast computer many years to solve. And in the same way as symmetric encryption, the longer the key, the harder it is to solve the problem.
Figure 7-16: Four-key encryption and authentication.
Hashing is a special form of one-way encryption that is used for passwords. It is another basic building bock used in DRM and computer authentication systems in general.
What we mean by "one-way" is that you can't undo it--the data that is hashed cannot be unhashed. Hashing "hashes up" a password in a predictable but irreversible way. What comes out of a hash is a new scrambled string. When someone enters a password to, say, get their email, the password is hashed, or turned into a longer string of characters. For instance, one possible hash of the word password is $1$0ZX5WIpr$HbsZvyyyeltL95mVikp831.
Now, $1$0ZX5WIpr$HbsZvyyyeltL95mVikp831 cannot be turned back into password, but hashing the word "password" always results in that same string if the same hashing technique is used. Thus, when the user types in his password, the hash of the password is compared to the stored password-hash. If they match, the user is let in. Note that in this case, the hash is larger than the password.
Hashes are used to avoid storing passwords in plaintext--that is, in clearly readable text. That is why most systems cannot tell you your password if you forget it; they can only have you create a new one. They don't know your password; they only know a hash of your password, from which they can't retrieve your password.
Figure 7-17: Hashing encryption is used to securely store passwords.
Another common use of hashing is to create what is called a signature (also called a fingerprint or a digest) for a file. This is a small file that can be used to uniquely identify a much larger file. For instance, many file-sharing programs use hashes to check whether a file has been successfully downloaded. Thus, hashes are a form of checksum as described in earlier chapters. These hashes are much smaller than the file. Instead of comparing the entire file, they simply compare the two hashes.
Note: Common acronyms you may encounter for hashing systems are MD5 (for "message digest") and SHA1 (for "secure hashing"). MD5 is still used by web servers and browsers to hash identify content. SHA-1 is more resistant to spoofing than MD5 and has replaced MD5 in many applications.
Figure 7-18: Hashes can also be used to checksum the integrity of a file.
In DRM systems, the software possesses the keys, not the user. The encryption is all going on behind the scenes. Usually what happens is that video is encrypted with a symmetric key, but the symmetric key is sent to the user via a small conversation using asymmetric encryption. The symmetric key remains encrypted on the user's hard drive or in memory, and the media player uses its own private key and the media server public key to decrypt it. The media player might have its own unique decryption key for that particular user. The asymmetric keys take care of all the questions in a typical transaction:
"Are you really the media server?"
"Are you really who you say you are, Joe User?"
"Have you paid for the content?"
"Yes I have, here's my receipt."
"Okay, here's the symmetric key to decode the movie."
Because symmetric keys are much faster to decrypt, they are used for the bulk of the data: the large movie file the user wants to watch. And the hash or checksum is used to verify the integrity of the whole file that is downloaded.
Because of all these keys, key management becomes an important part of any DRM system. In the case of Internet-based video distribution, some of the keys are usually stored securely by the media server or (in the case of some third-party systems) on a separate website with client software to communicate with that website.
Sometimes, it is necessary to revoke a key that has been granted--say, to remove Bill's ability to obtain content when he cancels his subscription, or even prevent him from continuing to view content he has already downloaded, as depicted in Figure 7-19. Systems vary in the way they implement this, but most media DRM systems are centralized, so there's not a lot of worry of "checks crossing in the mail." This is simple when the key is on the server.
Figure 7-19: Key revocation prevents a non-paying user from accessing the secure media.
This approach of granting and revoking server-stored keys helps prevent situations where the content is copied from user to user. Because the movie's symmetric key is locked inside an asymmetric key for that user only, if the locks are changed for that user, the user cannot get the key to the movie.
When the key is in the client, however, key revocation (changing the locks) can become trickier. For instance, a media player might have several private keys built into it. If those keys are compromised (for instance, discovered and published on the Internet), all the media players on the Internet might want to update their keys to new ones that haven't been made public. So they go to some sort of key server, find out what keys not to use any more and not to accept, and then download new private keys, which must be done securely as well (so they aren't altered in transit).
Digital signatures are built using hashes and asymmetric encryption. If you have a chunk of data that you want to send unencrypted, but you want the recipient to know for certain that it came from you, you do the following:
Just like a government or a bank serves as a trusted third party to verify identity in business and financial transactions, Internet systems often use a designated third party for digital signature and key exchange. In the case of web browsers, several companies have public keys built in to most web browsers. These companies (such as Thawte or Verisign) digitally sign other companies' public keys. These public keys are called certificates when they are presented to a user for acceptance by a web browser.
Thus, a chain of trust and security is created; your web browser trusts Verisign (the browser knows Verisign public keys and implicitly agrees that it is a trustworthy company), Verisign then securely sends (digitally sign) the certificate for Company XYZ, and now your web browser can trust encrypted messages from Company XYZ. (A whimsical certificate is depicted in Figure 7-20.)
Finally, the web browser connects to a URL, such as https://www.companyXYZ. com. Company XYZ's web server encrypts a temporary session key for symmetric encryption of that session's conversation (such as completing an online purchase). Because symmetric encryption is faster for the large amounts of data, the session key is used to encrypt all the secure web pages instead of Company XYZ's private key.
Figure 7-20: The browser trusts Verisign.com, and can communicate securely with Verisign. Verisign vouches for Company XYZ and now the browser can securely communicate with CompanyXYZ.com.
Simply stated, a software-only video DRM system that stores keys locally will eventually be hacked. The only insurance against this is the ability to patch and update all the existing and deployed compromised (or still compromisable) clients to repair the faults. The location of the locally stored keys could have been discovered; a way of disabling the checking with a central authority might have been devised. As long as the system is designed to shut down and refuse service to any older, non-upgraded media player when it attempts to acquire more content, the system is still workable.
What rights are DRM systems trying to manage? Not just "you're allowed" or "you're not allowed." DRM systems typically try to manage price, length of time, number of copies, copying to other devices, and license revocation. There's a lot there, so let's break it down into several business processes:
The financial transaction is not our concern here; a secure mechanism (https://, provided by a certificate authority as discussed earlier) allows for credit card processing or other payment methods. Figure 7-21 repeats our diagram of an idealized DRM system.
Figure 7-21: An idealized DRM system.
The building blocks that commonly provide for these processes are:
DRM technology has to be integrated into the content itself as well as into the encoding and playback system used. This is because it has to be locked, transported securely, and unlocked (with some sort of verification of rights) before it is watched.
For both streams and downloads, decryption occurs at the point that the content is viewed. For streams, that is immediate, and the license needs to be already there or acquired at the point the content is watched, as shown in Figure 7-22.
Figure 7-22: A DRM-wrapped file forces would-be viewers to purchase a license before they can access the file.
For downloads, the license does not need to be activated until the file is clicked for the first time. This allows download-based DRM to trigger an interaction (such as launching a web page where they user can pay for the content) in order to acquire a license. Downloadable media files can then be wrapped in DRM and traded freely because when they reach another computer, that computer (which lacks a license) needs to acquire one, repeating the procedure.
The example of a just-in-time (JIT) license acquisition for downloads is only one example business model, and although it is popular with content providers, there are many other ways to deploy and license content. The point is, these same DRM building blocks are used to implement rules in any media chain.
The fundamental difference between encryption techniques and DRM challenges is the trusted parties. In usual encryption scenarios, the end users are assumed trustworthy and a malicious third party is assumed to be the threat that the user needs to defend against. In contrast, DRM assumes that only the devices are trustworthy, and that the users are the potentially malicious interlopers. This is why DRM cannot depend on encryption technology alone--it is only one technical component of a complete DRM solution. Vendors that brag about the strength or complexity of their encryption are saying little about the robustness of their DRM.
Figure 7-23: Encryption assumes trustworthy end users and a malicious third party. DRM assumes that only the devices are trustworthy, and any user is potentially malicious.
Despite the difficulties described in this chapter, effective DRM is not completely impossible. If some sort of hardware or controlled environment is involved, it is certainly workable. Some of the more effective DRM technologies for video include:
If and when such initiatives come to fruition, the building blocks of an extremely robust and hack-proof computer DRM system will finally be available. (Search for "trusted computing" in Google to learn more about the pros, cons, and current standards groups working on these issues.)
These DRM systems work. Software-based DRM systems simply don't offer foolproof rights management. Software is hacked. Hardware requires them to break the law or violate their agreement, which by definition a small minority does. Software requires only a small minority to break the agreement or license in order for the majority to enjoy the benefits with little or no effort. When this is coupled with a system that reduces traditional rights instead of increasing them (as digital can technologically do), then it becomes a point of moral righteousness (or, the behavior of music consumers).
Conceptually, digital should be more open than analog, not less. This creates a climate where software developers who defeat DRM are sometimes characterized as heroes who liberate the content from oppressive content holders, whereas those who produce and sell cable descramblers are still viewed as somewhere between unethical and criminal. On the other hand, these moral arguments don't take into account the reduced revenues of digital distribution as compared to its analog counterparts.
This "Robin Hood" attitude towards content providers shows how important it is to implement a reasonable and user-friendly DRM solution if it is to be effective.
When evaluating DRM technologies for use in protecting content online, here's some final advice:
Here are some possible strategies for delivering online content without risking your revenue model:
The resulting effect is that copy protection needs to be just sufficient to make it difficult for the majority of the people to circumvent it, and that any circumvention requires deliberate and clearly infringing action.
It can be difficult to fully appreciate how secure DRM systems are without studying the complicated mathematics used to create symmetric and asymmetric keys. The main thing to know is that several different kinds of encryption are used for different parts of the DRM system, and that DRM involves all the elements of the system (the server, the transport, the media, and the client playback application) in order to be as secure as possible.
It is important to know the basics of what is occurring with any DRM solution are the same between systems--the same technical building blocks are used. DRM systems are far too new and varied to be called commodity technology (the term for relatively undifferentiated products that can be purchased from many vendors for a low price). Nonetheless, choosing the right DRM system can involve political, partnership, and trust decisions more than it depends upon substantial technical differences.| home / multimedia / video / 1 | [previous] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: May 24, 2004
URL: http://webreference.com/programming/xsltweb2/1
