Media player security for full length episodes

A streaming video player and authentication server work in conjunction to provide secure streaming media. Player authentication is used to ensure that only users using an authorized media player authorized users can access and stream the media content. An encryption process protects unauthorized users from playing media streams that are intercepted between the content server and an authorized user. Additionally, timed tokens are used to ensure that a user authorized to access a stream during a specified time period cannot access the same stream at a later time when the user is no longer authorized.

BACKGROUND

1. Field of Art

The disclosure generally relates to the field of security for web-based media streaming.

2. Description of Art

Web-based delivery of media content has become an increasingly popular form of content delivery for many content providers. For example, a number of content providers offer digital video content that can be streamed to network-enabled devices such as personal computers, television set-top boxes and mobile devices (e.g., smart phones). However, despite the many advantages of streaming media content, content providers still have significant concerns regarding security of the streamed content. In unsecured form, streaming media content may be susceptible to a variety of techniques that would allow unauthorized viewers to intercept or otherwise obtain the streamed content without permission from the content providers. For example, an unauthorized user could intercept a stream intended for an authorized user or an authorized user could share received content with unauthorized users. Weaknesses in digital security of web-based media streams can significantly impact revenue of content providers who rely on the ability to control access to their content.

DETAILED DESCRIPTION

Overview of Example Embodiments

A first example embodiment includes a computer-implemented method for obtaining secure streaming media content on one or more clients. A client transmits a request to an authentication server to authenticate a media player. The request includes at least one secret identifier of the media player. Responsive to the media player being authenticated, the client obtains from the server, an encrypted security asset storing the at least one security identifier in an encrypted format. A request for a media stream is transmitted to the authentication server and includes the encrypted security asset. Responsive to the authentication server verifying the encrypted security asset, playlist information is received identifying a sequence of media segments in a requested media stream. A request for a first media segment in the sequence of media segments is then transmitted based on the playlist information. This request includes the encrypted security asset. A first encryption key for decrypting the first media segment is received responsive to the authentication server verifying the encrypted security asset. The first encrypted media segment in the sequence of media segments is also received. The client decrypts the first encrypted media segment using the first encryption key and plays the first decrypted media segment using the media player.

A second example embodiment includes a computer-implemented method for providing secure media content. An authentication server authenticates a media player executing on a client based on at least one secret identifier transmitted from the client to an authentication server. The authentication server generates an encrypted security asset storing the at least one security identifier and storing a timestamp. The encrypted security asset is transmitted to the client. A request is received for a media stream. The request includes the encrypted security asset. The security identifier stored in the encrypted security asset is verified, and responsive to verification, playlist information is provided indentifying a sequence of media segment in the requested media stream. Responsive to receiving a request for a first media segment, the authentication server obtains a first encryption key for decrypting the first encrypted media segment and transmits the first encryption to the client.

System Architecture

FIG. 1is a high level block diagram illustrating an example computing environment100for providing secure streaming media content according to one embodiment. An authentication server110, a content server120, and a video processing server140are coupled to each other and/or one or more clients130via a network140. Only a single instance of the authentication server110, the content server120, and the video processing server140is shown along with three clients130inFIG. 1in order to simplify and clarify the description. However, embodiments of the computing environment100can have thousands or millions of clients130as well as multiple authentication servers110, content servers120, and/or video processing servers140. Furthermore, in one embodiment, one or more of the authentication server110, the content server120, and the video processing server140may be combined in a common server architecture.

The client130comprises an electronic device such as a personal computer, a laptop, mobile phone or smartphone, a tablet computer personal digital assistant (PDA) a television set-top box, etc. The client130executes a media player135that is adapted to play media streams. In one embodiment, the media player135comprises a Universal Video Player (UVP), but the embodiments described below also apply to other types of media players. In one embodiment, the media player135is embodied as computer program instructions stored to a computer-readable storage medium. When executed, the computer program instructions are loaded in a memory of the client130and executed by a processor of the client130to carry out the functions of the media player135described herein. In one example embodiment, the media player135is embedded or otherwise accessed from a mobile application executing on a mobile device. Alternatively, the media player135may be an embedded media player within a web page loaded by a web browser. In yet another embodiment, the media player135may be an application executing on a television set-top box or similar device. In one embodiment, the media player135is implemented using Objective C, although in other embodiments different implementations may be used such as Javascript. Furthermore, in one alternative embodiment, the media player135is compatible with an HTML 5 environment.

The network150enables communications among the entities connected to it. In one embodiment, the network150is the Internet and uses standard communications technologies and/or protocols. At least a portion of the network150can comprise a mobile (e.g., cellular or wireless) data network such as those provided by wireless carriers, for example, VERIZON, AT&T, T-MOBILE, SPRINT, O2, VODAPHONE, and other wireless carriers. In some embodiments, the network150comprises a combination of communication technologies. The network150can include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), long term evolution (LTE), 3G, 4G, digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc. Similarly, the networking protocols used on the network150can include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), hypertext transfer protocol secure (HTTPS), simple mail transfer protocol (SMTP), file transfer protocol (FTP), etc. The data exchanged over the network150can be represented using technologies and/or formats including hypertext markup language (HTML) (e.g., HTML 5), extensible markup language (XML), etc. In addition, all or some of links can be encrypted using encryption technologies such as the secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc. In another embodiment, the entities use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

The video processing server140receives raw media (e.g., a media file such as a video file or a live audio/video input) and processes the raw media to generate a format suitable for streaming. For example, in one embodiment, the video processing engine140processes media to enable HTTP Live Streaming (HLS) of the content. In one embodiment, the video processing engine140breaks the raw media into a sequence of smaller HTTP-based downloadable files. Each of these downloadable files is referred to as a segment and comprises a time-localized portion of the media file (e.g., a chunk of video). Different pluralities of segments may furthermore be grouped together into chapters, with each segment belonging to only one chapter. In one embodiment, the video processing server140may further transcode the media data to a standardized format. Furthermore, the video processing server140may create a plurality of parallel streams for the raw media file with each stream corresponding to at least one different encoding parameter. For example, the video processing server140may generate two or more streams of the content with each stream having a different bit rate. This allows, for example, different clients130to access different versions of the same media content depending on the particular configuration of the client130(e.g., memory and/or processing power) and the current network conditions (e.g., available network bandwidth).

For secure streaming, the video processing server140encrypts the media segments using an encryption key. In one embodiment, for example, a unique encryption key is created for each chapter of a media stream for a particular bit rate. Thus, in this embodiment, all of the segments corresponding to the same bit rate and within the same chapter are encrypted using the same unique encryption key. In an alternative embodiment, encryption keys are not necessarily unique between bit rates or between chapters (e.g., the same encryption key may be used for the entire stream). In another alternative embodiment, the encryption key for a segment may be unique even between segments within the same chapter. In one embodiment, the encryption key is based on at least a portion of the chapter title or other identifier and/or at least one secret key file. For example, in one embodiment, the encryption key is an output of a hash function applied to the chapter identifier and the secret key file. This would allow, for example, the encryption key for a given segment to be determined if the chapter identifier, secret key file, and the hash function are all known. The encrypted segments are stored to the encrypted content database122of the content server120.

The video processing server140furthermore creates a master index and one or more playlist files associated with each media stream. The master index (in some protocols referred to as a “variant playlist”) comprises references or links (e.g., URLs) to the one or more playlist files. Each of the playlists referenced in the master index correspond to the different streams of the media content encoded according to different encoding parameters (e.g., bit rate). For example, a first playlist referenced in the master index may correspond to a low definition bit rate, a second playlist referenced in the master index may correspond to a medium definition bit rate, and a third playlist referenced in the master index may correspond to a high definition bit rate. Each playlist includes a sequence of links (e.g., HTTP or HTTPS URLs) to different segments of the streaming media content. In one embodiment the playlist is an M3U8 playlist. The video processing server140provides the master index and the playlists to the authentication server110for storage in the master index database118and playlist database119respectively.

The authentication server110controls access of the clients130to the streaming media content and ensures that only authorized clients130are granted access. Generally, the authentication server110receives requests for content from a client130and determines whether or not the client130is authorized to receive the stream. The authentication server110denies access to unauthorized clients130and grants access to authorized clients130. In one embodiment, the authentication server110comprises a security asset generator122, a token generator124, an encryption key generator126, a player whitelist117, a master index database118, and a playlist database119. In alternative embodiments, different or additional components may be included.

The master index118, player database119, and player whitelist117store various data used by the authentication server110to control access to secure streaming media content. For example, the master index118and player database119store master indices and playlists respectively for various media streams, as described above. The player whitelist117stores information identifying valid media players135, i.e., media players that are authorized to access the streaming content. For example, in one embodiment, the player whitelist117stores various security data associated with players135seeking access to content. The authentication server110can compare security data received from a requesting client130against entries in the whitelist117and allows access to the content if an entry matches (or alternatively, deny access to the content if no entry matches). The security data may include, for example, a secret identifier associated with the media player135, and/or a username/password associated with a particular authorized viewer making the request.

The security asset generator112generates security assets for clients130once they are authorized to access streaming media content. For example, in one embodiment, the security asset comprises a web cookie that stores security data associated with the authorized client130in encrypted form. An encryption key for decrypting the security asset is known to the authentication server110, but is kept secret from the client130. Thus, individuals are prevented from extracting the security data stored in the encrypted asset. The security asset is used by the clients130and the authentication110in facilitating secure streaming of content, as will be described in further detail below.

The encryption key generator116generates or obtains encryption keys associated with each requested content segment. In one embodiment, the encryption key for a particular segment is stored at a static URL location (e.g., located on the content server120), and the encryption key generator116requests and obtains the encryption key whenever a particular content segment is requested from an authorized client130. Alternatively, the encryption key generator116dynamically generates the correct encryption key (i.e., the same encryption key used by the video processor140to encrypt the segment) for decrypting a particular content segment in response to receiving a request from a client130for that particular content segment. For example, if the content segment is encrypted using an encryption key that is based on a chapter identifier and a secret key file, as described above, the encryption key generator116can determine the correct encryption key based on the chapter identifier for the requested segment and the secret key file.

The token generator114generates timed tokens that can be associated with encryption keys passed between the authentication server110and the client130. For example, in one embodiment, the token generator114tokenizes a URL or other reference corresponding to the encryption key's location on the authentication server110. The token comprises a set of characters that appear in the link (e.g., within a URL address) associated with the encryption key. Thus, to obtain the encryption key, the client130makes a call to the authentication server110using the appropriate link (e.g., URL address) that includes the correct token. If the token is incorrect, the authentication server110will not return the encryption key. In one embodiment, the token's validity is limited to a predetermined period of time (e.g., 3 hours). Thus, after the time period expires, the tokenized link associated with the encryption key will no longer be valid for obtaining the encryption key, and a different token may instead be assigned. It is noted that the predetermined period of time can correspond with a length of a media event that may be represented by the media that is streamed.

The content server120provides media content to authorized clients130. For example, in one embodiment, the content server120receives a request for a particular content segment. The content server120provides the requested segment to the requesting client130in encrypted form (e.g., from encrypted content segments database122). In one embodiment, links (e.g., URLs) pointing to the location of the segment on the content server120may be tokenized so that the content server110only returns the requested segment if the correct token is provided. These tokens generally have a limited valid lifetime so that the token associated with a particular segment dynamically changes over time. Operation of the content server120in conjunction with requests for streaming content is described in further detail below.

Example Operation and Use

FIG. 2illustrates an embodiment of a process for obtaining a secure media content stream. The client130receives202a request for streaming media content (e.g., from a user via a user interface). For example, a user of the client130may select content for streaming from a list of selectable content on a web page. Alternatively, the user may select content using an application executing on the client130(e.g., an application executing on a mobile device). The client130then attempts to authenticate204the media player135with the authentication server110. In this authentication step204, the client sends security data associated with the player135to the authentication server110and the authentication server110verifies whether or not the player135is authorized to receive the requested content based on the security data. Requiring player authentication beneficially ensures that the player is authentic, i.e., a player that the content provider intends to be allowed to stream its content. Thus, if a user tries to access the video stream using a different player (e.g., one provided by another entity or one created or modified by the user), the authentication server120will not authenticate the player because the player will be unable to provide valid security data. In one embodiment, the security data is transferred in encrypted form (e.g., via HTTPS). This prevents potential eavesdroppers from obtaining the security data of another authorized user. Furthermore, the authentication step204could optionally ensure that the user making the request is authorized. For example, the client130may obtain a username and password from the requestor, and include this information in security data transmitted to the authentication server110. A process for authenticating204the media player135is described in further detail below with reference toFIG. 3.

The client130then obtains206a master index (e.g., from the master index database118) and one or more playlists (e.g., from the playlists database119) associated with the requested media stream. In one embodiment, this information is also provided in encrypted form (e.g., via HTTPS). In one embodiment, the client130initially selects one of the playlists (corresponding to a particular encoding of the media stream) based on, for example, a default initial setting or monitored characteristics of the network150, client130, and/or the authentication server110. Beginning with the first segment in the selected playlist, the client130obtains208an encryption key corresponding to the current segment. The client130then obtains210the encrypted segment referenced in the playlist, if it is not already locally available. For example, as described above the client130may use the same encryption key for all of the segments corresponding to a particular chapter and therefore does not need to re-obtain the encryption key with each segment. Alternatively, a different encryption key may be used for each segment, or the same encryption key may be used for the entire stream. By encrypting the segments, the media stream is protected against users attempting to share the media stream with unauthorized users. Even if the data files are shared, they will not be decipherable without the corresponding encryption keys. Furthermore, by using timed tokens, the links (e.g., URLs) provided in the playlists that are used to obtain the encryption keys and the content segments will only be valid for a limited period of time. This enables the content provider to control the period of time for which content is accessible for a particular user.

The client130decrypts212the encrypted segment using the encryption key. Once the segment is decrypted, the client plays214the segment using the media player135. Steps208-214then repeat216for the next segment in the playlist. Over time during streaming, the client130may switch between different playlists (corresponding to different encoding parameters) based on streaming performance. For example, if the bandwidth of the network connection is too low to support the bit rate of the selected playlist, the client may switch to a playlist corresponding to a lower bit rate. Alternatively, if the network bandwidth is high enough to support a playlist corresponding to a higher bit rate, the client130may switch to the higher bit rate playlist in order to provide better quality video content.

FIG. 3illustrates an embodiment of processes performed by the client130and authentication server110for authenticating204the media player135and/or the user making the request. The client130loads302the media player, which may be in the form of, for example, a mobile application or portion thereof, an embedded player on a web page, an application executing on a television set-top box, etc. The client130sends304security data to the authentication server110to verify that the client130is authorized to access the requested content (e.g., via HTTPS or other encrypted protocol). For example, in one embodiment, the client130sends one or more of a player identifier, an application identifier, and a session identifier as the security data. The player identifier is a set of characters associated with the media player135. For example, the player identifier may be embedded in the program instructions associated with the media player135so that an authentic player can be distinguished from a third-party player that would lack the correct player identifier. The application identifier comprises a set of characters unique to the application used to load the media player135. The session identifier comprises a set of characters identifying the particular streaming session associated with a single request for video content. For example, in one embodiment, a new session identifier is randomly generated each time a request for streaming content is made and the session identifier remains constant throughout streaming of that requested content, or for a predefined period of time. Optionally, the client130also sends a username and password associated with the user making the request together with the player security data.

The authentication server110attempts to verify306at least some of the security data against the player whitelist117. For example, in one embodiment, the authentication server110attempts to verify306that the received player identifier and application identifier match an entry in the player whitelist117. In one embodiment, the authentication server110also attempts to verify306the username and password against entries in the whitelist117. In one embodiment, the session identifier is not verified in this step306because it is generated when the session starts and is not yet known to the authentication server110. Alternatively, the session identifier may still be checked to make sure it is authentic even if the exact value is not known in advance by, for example, verifying that the session identifier has a particular format or checksum. The authentication server110then generates308an encrypted security asset (e.g., a web cookie) using the security asset generator112. The security asset stores the received security data (e.g., the player identifier, application identifier, session identifier, and optionally a username/password) in an encrypted form that can be decrypted using an encryption key known to the authentication server110, but typically secret from the client130.

In one embodiment, the encrypted security asset further stores a timestamp generated by the authentication server110when the security asset is created. This timestamp can be used to ensure that the encrypted security asset will only be valid for a limited period of time, and enables the authentication server to prevent a user from using the same security asset to obtain the streams at a later time when the user is not authorized. The authentication server110sends310the encrypted security asset to the client130(e.g., using HTTPS or another encrypted protocol) and the client130stores312the encrypted security asset. The encrypted security asset serves as evidence that the player135executing on the client130has been authenticated and remains valid until the security asset expires.

FIG. 4illustrates an embodiment of a process for securely obtaining the master index and playlists corresponding to the requested media content. The client130sends402(e.g., via HTTPS or other encrypted protocol) a request to the authentication server110for the master index and sends its security data (e.g., the player identifier, the application identifier, and the session identifier) and the encrypted security asset to the authentication server100. The authentication server110then decrypts the security asset and attempts to verify404the security data. For example, the authentication server110ensures that the player identifier and application identifier match an entry in the player whitelist117and ensures that the player identifier and application identifier match the corresponding data stored in received the encrypted security asset. Furthermore, the authentication server110checks the timestamp to ensure that it is not expired. If a username and password are required, the authentication server110may also verify these against the whitelist117. In an alternative embodiment, the client130may instead transmit only one of the security data and the encrypted security asset in this step since the information is redundant. However, this redundancy may be beneficial in providing an additional layer of security (e.g., if a user attempts to transfer a valid security asset from one device to another or if a user gains access to the security information itself). If the security data cannot be verified, the authentication server110may deny the request for the master index.

If the security data is verified, the authentication server110sends406the master index to the client130(e.g., via HTTPS or other encrypted protocol) and the client130stores408the master index. The client130then requests410one or more of the playlists using the links (e.g., URLs) provided in the master index (e.g., via HTTPS or other encrypted protocol). The client furthermore sends with this request, the encrypted security asset containing the encrypted security data (or alternatively, or in addition, the security data itself). The authentication server110decrypts the encrypted security asset and attempts to verify412the security data against the entries in the player whitelist117. If the security data cannot be verified (i.e., does not match an entry in the whitelist117) or if the timestamp is expired, the authentication server110may deny the request. If the security data is verified and the timestamp is not expired, the authentication server110returns414the requested playlist (e.g., via HTTPS or other encrypted protocol) and the client130stores416the playlist. As explained previously, the links (e.g., URLs) for the content segments may be tokenized, i.e., the link includes a token (e.g., a set of characters) that can change dynamically over time, so that the tokenized reference in the playlist only points to the segment file for a limited time period, after which the token associated with that segment file may change.

Furthermore, the link (e.g., URL) associated with the encryption key may also be tokenized, so that the link only references the encryption key for a limited period of time, after which the token will expire. In one embodiment, the links for the encryption keys are masked links (e.g., masked URLs). In the masked link, a portion of the link that identifies the content segment is encrypted so that viewing the characters in the link alone will not reveal which content segment it corresponds to. The key for decrypting the masked link is known to the authentication server110. The client stores416the received playlist to the playlist database119.

FIG. 5illustrates an embodiment of a process for obtaining an encryption key for the current video segment, if not already available (e.g., because the same encryption key was used for the prior segment and the client130therefore already has the appropriate key). The client130request502(e.g., via HTTPS or other encrypted protocol) the encryption key from the authentication server110by using the links (e.g., HTTPS URLs that may be masked URLs and may include a timed token) specified in the playlist, and furthermore sends its encrypted security asset. The authentication server110again attempts to verify504the encrypted security asset by ensuring that the player identifier and application identifier (and optionally username/password) match the player whitelist and the timestamp is not expired. Furthermore, the authentication server110verifies that the timed token associated with the request is valid and not expired. If the all information is verified, the authentication server110decrypts506the masked portion of the link if necessary to determine which segment is being requested. The authentication server110then obtains508the encrypted key for the requested segment. In one embodiment, the encryption key associated with the content segment may be dynamically generated when the request for the playlist is received (e.g., using the encryption key generator116). Alternatively, rather than dynamically generating the encryption key, the authentication server110instead merely requests the encryption key from a static URL (e.g., a URL on the content server120) that is known to the authentication server110. The authentication server110then sends512the encryption key to the client130via an encrypted protocol (e.g., HTTPS).

FIG. 6illustrates an embodiment of a process for decrypting a segment using the encryption key. The client130requests602a media segment from the content server120using the link in the playlist associated with the media segment (e.g., a URL with a timed token). The content server120verifies604that the link to the requested segment is valid and the time token is valid and not expired. If the request is verified, the content server120sends606the encrypted segment to the client130. In one embodiment, the segment is sent via an unsecure protocol (HTTP) rather than an encrypted protocol such as HTTPS because the segment itself is already encrypted. The client130decrypts608the segment using the encryption key and plays the segment through a media player.

Beneficially, the described embodiments enable secure media streaming of content using a protocol such as HLS. By employing a player authentication technique, content providers can ensure that only users using an authorized player are allowed to access the content, thus preventing access to content using custom-made players. Furthermore, by using encryption of media segments, the streams are protected from eavesdroppers that seek to intercept a stream transmitted to an authorized user. Additionally, by using security assets, timed tokens, and other exchanges of secure information, an authorized user is prevented from sharing a stream with an unauthorized device or re-accessing a stream during a later time period when the user is no longer authorized.

Additional Considerations