Difference between revisions of "svcAuth"

From NMSL
 
Line 1: Line 1:
 
== Downloads ==
 
== Downloads ==
  
svcAuth is an ongoing project and is continuously improved. The latest version of svcAuth can be accessed through [https://cs-svn.cs.surrey.sfu.ca/nsl/browser/svcAuth our subversion system]. svcAuth can also be downloaded as a single zipped file 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].
+
svcAuth is an ongoing project and is continuously improved. The latest version of svcAuth can be accessed through [https://cs-git-research.cs.surrey.sfu.ca/nsl/Security/svcAuth our git system]. svcAuth can also be downloaded as a single zipped file 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 ==
 
== Introduction to svcAuth ==

Latest revision as of 10:43, 22 September 2017

Downloads

svcAuth is an ongoing project and is continuously improved. The latest version of svcAuth can be accessed through our git system. svcAuth can also be downloaded as a single zipped file from here. svcAuth is released under GPLv3.

Introduction to svcAuth

We have designed and implemented a library for authenticating scalable video streams encoded using the state-of-the-art H.264/SVC video coding standard, the Scalable Video Coding (SVC) extension of H.264/AVC standard; the library can thus authenticate H.264/AVC streams as well. The library is called svcAuth, and is implemented in Java to support portability across different platforms. svcAuth supports the full flexibility of H.264/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 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.


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 (H.264's Network Abstraction Layer) 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 (Group-of-Pictures), 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 an SVC bitstream. This is done by encapsulating the authentication information as appropriate NAL units and inserting them to the original bitstream. We use Supplemental Enhancement Information (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 all required hash 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.


Related Resources


People