Freigeben über

The encryption of Windows Azure Media Services

  • Artikel

Windows Azure Media Services provides additional security protection for videos assets. The video asset uploading to Windows Azure Media Services can be encrypted using ECB algorithm. The entity used in Windows Azure Media Services is ContentKey, which stores X.509 encrypted ECB key. There are several common questions for the encryption system for Windows Azure Media Services, I am trying to answer them in this post. 

a. Why do we need another encryption mechanism, is the connection already secure?

The connection between the client and server in Windows Azure Media Services is protected via https protocol. However, https protocol is not absolutely secure, in particular, if the https traffic is hijiacked from the very beginning, hackers should be able to decrypt all the subsequent traffic. 

b. Why do we need two keys, ECB and RSA? What do they do each? Can we just use one?

ECB algorithm is used to encrypt and decrypt the video. ECB is a very fast encryption algorithm which uses the same key to perform encryption and decryption. If we only use ECB to encrypt the video asset, we also need to send the ECB key from client to the server, if the hacker hijack the ECB key, he will be able to decrypt the traffic and fake the client. To prevent this from happening, an asymetric encryption algorithm RSA is used to provide further security for assets. The key for RSA protocol in Windows Azure Media Services is called ProtectionKey. A protection key contain a public key and a private key, the private key never be released to the client. By calling get protection key ID method, client can obtain the ID of the protection key that is in use for the specified protocol. Another call of get protection key method will return the public key of the RSA key. When the client obtain the public key, the client can use the public key to encrypt the ECB key and send the encrypted ECB key as content key to server. Because only Windows Azure Media Services has the private key, even if the hacker hijack the traffic in between, it still cannot decrypt the ECB key from the content key. As a result the security of the video asset get protected.

Comments

  • Anonymous
    January 06, 2014
    Hey Albert, From what you are saying, it seems that the server will be encrypting the video on the fly using the ECB symmetric key sent by the client. The client would then use the same ECB key to decrypt the content. Yet, the general experience is that the content is usually  pre-encrypted and stored on a CDN that can deliver pre-encrypted content without knowing anything about the encryption process. Can you shed some light please?

  • Anonymous
    January 06, 2014
    Thanks for the input Albert. I think that confuses me even more. Your original expose suggested that the client generates the ECB key, encrypt it and send it to the server. If this is the case, how then can the server encrypt a video, store it in the CDN and have it used by all clients? This would assume that all clients would have the same ECB key, which would contradict what we started with, which is that the client generates the ECB keys. Am I missing something?

  • Anonymous
    January 06, 2014
    Hi Max, my reply was a little bit confusion indeed. I deleted it. The more typical workflow is a.  the uploading client encrypt the asset using the ECB key, the Windows Azure Media Services got the initially encrypted media asset.

  1. Then the uploading client sends the ContentKey containing RSA encrypted ECB key to the Windows Azure Media Services.
  2. Afterwards, the uploading client will start a decryption Job/Task to ask the server (Windows Azure Media Services) to decrypt the encrypted media asset. The decrypted media asset will be placed on CDN to be viewed by end customer. Hope this is clearer.
  • Anonymous
    July 06, 2014
    Based on step #3 "The decrypted media asset will be placed on CDN to be viewed by end customer, this would mean the content is only encrypted in-transit and not while at-rest. With direct URL access to the asset, a hacker could download the asset easily, this defeating the purpose. Question is:
  1. what will the download/playback by the client workflow in this scenario?
  2. Is step #3 really necessary? can't we simply store the "encrypted" asset on azure and let the client decrypt it after it downloads? Thanks!