Difference between revisions of "svcAuth"
| Line 1: | Line 1: | ||
== Downloads == | == Downloads == | ||
| − | |||
| − | |||
| + | svcAuth is an ongoing project its software is continuously improved. The latest version of svcAuth can be accessed through our subversion system at [https://cs-svn.cs.surrey.sfu.ca/nsl/browser/svcAuth our subversion server]. svcAuth as a single zipped file can also be downloaded from [http://nsl.cs.sfu.ca/resources/svcAuth.tar.gz here]. svcAuth is released under [http://www.gnu.org/licenses/gpl-3.0.txt GPLv3]. | ||
| − | == | + | |
| + | == Introduction to svcAuth == | ||
We have designed and implemented an authentication schemes for H.264/SVC streams, called ''svcAuth''. svcAuth supports the full flexibility of SVC and allows verification of all possible substreams. In addition, it is designed for end-to-end authentication, in which only the content provider and the receiving devices need to be aware of the authentication mechanism. Therefore, when distributing multimedia streams in large scale over third-party Content Distribution Networks (CDNs), which contain proxies that may adapt scalable streams for different users, the proxies do not need to understand the authentication scheme, i.e., the authentication process and the authentication information embedded in streams are transparent; these information are embedded in SVC streams in a format-compliant manner. | We have designed and implemented an authentication schemes for H.264/SVC streams, called ''svcAuth''. svcAuth supports the full flexibility of SVC and allows verification of all possible substreams. In addition, it is designed for end-to-end authentication, in which only the content provider and the receiving devices need to be aware of the authentication mechanism. Therefore, when distributing multimedia streams in large scale over third-party Content Distribution Networks (CDNs), which contain proxies that may adapt scalable streams for different users, the proxies do not need to understand the authentication scheme, i.e., the authentication process and the authentication information embedded in streams are transparent; these information are embedded in SVC streams in a format-compliant manner. | ||
| − | svcAuth can be employed by any multimedia streaming application as a software/hardware add-on and without requiring any change to the encoders/decoders. Specifically, we add one authentication module to the provider side, which performs a post-processing on the encoded stream and embeds in it the information required for verification. At the receivers, we add a verification module, which verifies the received stream using the information embedded in it, and passes the verified stream to the player. Note that receivers who do not have the verification module and do not support the svcAuth authentication scheme can still receiver and decode the streams, since the scheme is transparent. | + | svcAuth can be employed by any multimedia streaming application as a software/hardware add-on and without requiring any change to the encoders/decoders. Specifically, as shown in the following figure, we add one authentication module to the provider side, which performs a post-processing on the encoded stream and embeds in it the information required for verification. At the receivers, we add a verification module, which verifies the received stream using the information embedded in it, and passes the verified stream to the player. |
| + | |||
| + | [[Image:svcAuth_placement.png|center|border|456px]] | ||
| + | |||
| + | |||
| + | Note that receivers who do not have the verification module and do not support the svcAuth authentication scheme can still receiver and decode the streams, since the scheme is transparent. | ||
| + | |||
| + | svcAuth is available as an open-source library implemented in Java, to support portability across different platforms. | ||
| + | |||
| + | |||
| + | |||
| + | == Overview of svcAuth Architecture == | ||
| + | |||
| + | The svcAuth authentication module, which is used at the content provider side, is shown below: | ||
| + | |||
| + | |||
| + | [[Image:svcAuth_auth_module.png|center|border|450px]] | ||
| + | |||
| + | |||
| + | This module is placed after the video encoding process and before transmission, and operates as follows. The video stream is first parsed by the Stream Parser module, which extracts NAL units from the bitstream, parses their headers, and delivers them as logical objects to the SVC Reader module. The SVC Reader module determines the structure of the SVC stream using the NAL units. For this purpose, as shown in the figure, it needs to buffer a number of NAL units, e.g., to determine the last NAL unit of the current video frame which is done by detecting the first NAL unit of the next frame. The SVC Reader module outputs a logical view of the stream as GoPs, frames, and different types of layers. We refer to these entities as SVC Elements. | ||
| + | |||
| + | Each SVC Element in the logical view returned by SVC Reader contains an array of authentication information messages, which is initially empty. These arrays are filled by the SVC Auth module. The SVC Auth module takes as input a block of ''n'' GoPs, computes the required authentication information, and adds them to the SVC Elements of those ''n'' GoPs. The output of SVC Auth, which is the same set of GoPs as the input with authentication information added, is delivered to the SVC Writer module. The SVC Writer module converts back the logical structure to a raw bitstream. This is done by encapsulating the authentication information as appropriate NAL units and inserting them to the original bitstream. We use SEI NAL units (NAL unit type 6) of H.264/SVC for this purpose. An SEI NAL unit can contain one or more SEI Messages. To attach some information to a specific layer, we embed these information in an Unregistered User Data SEI message, relate it to the desired temporal/spatial/quality layer by encapsulating (nesting) it in a Scalable Nesting SEI Message, and finally encapsulate the result in an SEI NAL unit. | ||
| + | |||
| + | The svcAuth verification module operates similar to the authentication module with minor differences. The received substream first goes through Stream Parser and SVC Reader modules and reaches a module called SVC Verif. SVC Verif proceeds in a similar way to SVC Auth: it recomputes spatial layer, frame, GoP, and block digests from the reconstructed video, and compares them to the digests provided as the authentication information. In case of any mismatch, the mismatching part of data, such as a video frame, is marked as unauthentic and is discarded. The remaining parts are known as authentic if and only if the digital signature of the corresponding GoP block is successfully verified. The output of SVC Verif is sent to the receiver application for playback. | ||
| + | |||
| + | |||
| + | |||
| + | == People == | ||
| + | |||
| + | * [http://www.cs.sfu.ca/~mhefeeda/ Mohamed Hefeeda] (Assistant Professor) | ||
| − | + | * [http://www.cs.sfu.ca/~kma26/personal/ Kianoosh Mokhtarian] (MSc Student) | |
Revision as of 00:33, 23 June 2009
Downloads
svcAuth is an ongoing project its software is continuously improved. The latest version of svcAuth can be accessed through our subversion system at our subversion server. svcAuth as a single zipped file can also be downloaded from here. svcAuth is released under GPLv3.
Introduction to svcAuth
We have designed and implemented an authentication schemes for H.264/SVC streams, called svcAuth. svcAuth supports the full flexibility of SVC and allows verification of all possible substreams. In addition, it is designed for end-to-end authentication, in which only the content provider and the receiving devices need to be aware of the authentication mechanism. Therefore, when distributing multimedia streams in large scale over third-party Content Distribution Networks (CDNs), which contain proxies that may adapt scalable streams for different users, the proxies do not need to understand the authentication scheme, i.e., the authentication process and the authentication information embedded in streams are transparent; these information are embedded in SVC streams in a format-compliant manner.
svcAuth can be employed by any multimedia streaming application as a software/hardware add-on and without requiring any change to the encoders/decoders. Specifically, as shown in the following figure, we add one authentication module to the provider side, which performs a post-processing on the encoded stream and embeds in it the information required for verification. At the receivers, we add a verification module, which verifies the received stream using the information embedded in it, and passes the verified stream to the player.
Note that receivers who do not have the verification module and do not support the svcAuth authentication scheme can still receiver and decode the streams, since the scheme is transparent.
svcAuth is available as an open-source library implemented in Java, to support portability across different platforms.
Overview of svcAuth Architecture
The svcAuth authentication module, which is used at the content provider side, is shown below:
This module is placed after the video encoding process and before transmission, and operates as follows. The video stream is first parsed by the Stream Parser module, which extracts NAL units from the bitstream, parses their headers, and delivers them as logical objects to the SVC Reader module. The SVC Reader module determines the structure of the SVC stream using the NAL units. For this purpose, as shown in the figure, it needs to buffer a number of NAL units, e.g., to determine the last NAL unit of the current video frame which is done by detecting the first NAL unit of the next frame. The SVC Reader module outputs a logical view of the stream as GoPs, frames, and different types of layers. We refer to these entities as SVC Elements.
Each SVC Element in the logical view returned by SVC Reader contains an array of authentication information messages, which is initially empty. These arrays are filled by the SVC Auth module. The SVC Auth module takes as input a block of n GoPs, computes the required authentication information, and adds them to the SVC Elements of those n GoPs. The output of SVC Auth, which is the same set of GoPs as the input with authentication information added, is delivered to the SVC Writer module. The SVC Writer module converts back the logical structure to a raw bitstream. This is done by encapsulating the authentication information as appropriate NAL units and inserting them to the original bitstream. We use SEI NAL units (NAL unit type 6) of H.264/SVC for this purpose. An SEI NAL unit can contain one or more SEI Messages. To attach some information to a specific layer, we embed these information in an Unregistered User Data SEI message, relate it to the desired temporal/spatial/quality layer by encapsulating (nesting) it in a Scalable Nesting SEI Message, and finally encapsulate the result in an SEI NAL unit.
The svcAuth verification module operates similar to the authentication module with minor differences. The received substream first goes through Stream Parser and SVC Reader modules and reaches a module called SVC Verif. SVC Verif proceeds in a similar way to SVC Auth: it recomputes spatial layer, frame, GoP, and block digests from the reconstructed video, and compares them to the digests provided as the authentication information. In case of any mismatch, the mismatching part of data, such as a video frame, is marked as unauthentic and is discarded. The remaining parts are known as authentic if and only if the digital signature of the corresponding GoP block is successfully verified. The output of SVC Verif is sent to the receiver application for playback.
People
- Mohamed Hefeeda (Assistant Professor)
- Kianoosh Mokhtarian (MSc Student)
