1. 01/17/2007 Research on Channel-Independent Secure Live Communication Embedding Authentication Information Kyushu-univ. Okamura lab Kazuhisa Nakagawa

2. 01/17/20071 Contents Background –Live communication and channel-based encryption Purpose and policy –Dependable live communication with data authentication Proposal technique –Embedding authentication information between input device and server Solution –Software Interface & Additional hardware implementation –Application for data frame creating and verification DVTS implementation –IEEE1394, DV-format, No-compression Conclusions –Future work

3. 01/17/20072 Background (1/3) - Communication using wideband Internet - –Live communication over the Internet Real-time data transmission Live streaming –Low-latency video and audio data transmission –Teleconference, Remote surveillance, and so on. Input device Raw data production Server IP encapsulation Client Data extraction Output device Data playback Internet Data transmission Start Receiving Real-time decoding Start sending Real-time encoding data IP/UDP data IP/UDP data IP/UDP data Time sequence (Receiver)Time sequence (Sender)

4. 01/17/20073 Background (2/3) - Internet threat and channel-based encryption - –Network threat and defensive action Increase of unlawful computer access –Tapping, Falsification of data, Sender spoofing, … Lower layer encryption –VPN (Virtual Private Network), IPsec (IP Security Protocol) –Data encryption after IP encapsulation. Upper layer encryption –SSL (Secure Sockets Layer), SSH (Secure Shell) –Data encryption between Application layer and IP layer. The target is application layer. Channel-based encryption These methods enable channel security.

5. 01/17/20074 Background (3/3) - Falsification of data in server - –Falsification in live communication Although falsification happens in application layer at server, client receives fake data continually. Channel-dependent secure live communication Channel-dependent has a limited security with respect to the falsification of data. × Falsification Channel-based encryption Cracker penetrate server ． (unlawful computer access) Cracker make the falsification. ・ prepared fake data ・ switch to another input device Client receives fake (not purposive) data through secure channel between server and client. data IP/UTP data? IP/UDP

6. 01/17/20075 Purpose and policy (1/2) - Dependable live communication with data authentication - –Authentication to the large-volume data streaming Client verifies data streaming and checks whether server is sending a purposive data or not. Realization of the mechanism that verifies no falsification (detection of data switching) in live communication. Secure channel enable dependable Real-time data transmission, but receiver should depend sender’s data streaming. Authentication between data sending server and data receiving client Client can identify a server (the end of secure channel), but cannot identify a data itself in live communication.

7. 01/17/20076 Purpose and policy (2/2) - Related Work - –Digital watermarking Watermarking for video helps protect the copyright of the video content. It requires low influence on content itself. –Data streaming is watermarked in application layer. –My research focus on authentication information embedding to the raw data. compression Multiplexing packetization Watermark Embedding Decompress Watermark detecting Data streaming copyright Data streaming Reassembly Demultiplexing Internet Cracker threatens to penetrate an application layer.

8. 01/17/20077 Proposal technique (1/2) - Embedding authentication information - –Embedding between input device and server Sender’s application layer receives live streaming authentication information already embedded ． Receiver's application layer verifies authentication information in live communication. data IP/UDP data IP/UDP data IP/UDP Establish a reliability in data transmission Secure = Channel (end-to-end) Receiver verify the authentication information and confirm that the data has produced from a purposive input device. data IP/UDP data IP/UDP data verification data Embedding data IP/UDP extend a reliability to raw data (input device) Secure = Between input device and client ※ Embedding authentication information in live streaming

9. 01/17/20078 Proposal technique (2/2) - My research approach - –Software Interface @ sender embed authentication information (A-info) in a specific period. –Additional hardware implementation @ sender Activates software interface and checks device connection –Application @ server and receiver Authentication mechanism adapted to live streaming Sender makes two types of data frame. Receiver enables verification. Software Interface Hardware for A-info Sender Application Receiver Application activate

10. 01/17/20079 Solution (1/7) - Software Interface - – Middleware between physical interface and sender application Physical interface transfers raw data to software interface. Temporary data buffering Issues authentication information (A-info) specified by client –Received before starting live communication physical Interface physical Interface Software Interface Sender Application data Hardware for A-info memory field that transferred raw data from physical interface （ software interface designates ）

11. 01/17/200710 Solution (2/7) - Data transaction in physical interface- –Isochronous data transaction implemented in USB2.0 and IEEE1394 maximum 1024byte data transmission in 125μs periods data minimum 125μs Isochronous data transaction executes in 125μs periods constantly. Application execute systemcall and move raw data to memory area that execute IP encapsulation or compression. IEEE1394 Interface IEEE1394 Interface data （ 100μs ＝ 0.1ms ＝ 0.0001s ） data memory field that transferred raw data from input device （ OS designates ） The timing issuing A-info needs flexibility and should be able to control by sender.

12. 01/17/200711 Solution (3/7) - Periods embedding authentication information - –Provided by sender’s policy View from sender’s application… –It needs timing-synchronization based on IP-encapsulate. –Sender transmit an encapsulated data to channel (the Internet). View from input device… –A-info should embed each end of one frame that input device output at flame rate interval. Prepare a data frame embedding A-info individually (1 flame) Sending data frames filled usual data (multiple flame) data IP/UDP A-info Standards for televisionFlame Rate NTSC (National Television System Committee)29.97fps PAL (Phase Alternating Line) SECAM (Séquentiel couleur à mémoire) 25fps ISDB （ Integrated Services Digital Broadcasting 30fps

13. 01/17/200712 Solution (4/7) - Hardware implementation - –To make the authentication mechanism securer Cracker aims A-info itself. –It is not enough to realize a secure live communication with only software implementation. keep cracker from tampering with A-info –This mechanism demands highly confidential A-info and flexible A-info issuing. Strictly saying, encryption of A-info and temporary storage area, separated from server are needed. Extra memory area that cracker cannot get A-info received by client previously is needed. If cracker gets superuser authority, all software in server are in danger of cheating. It is not realized by modules, but can be simulated by modules.

14. 01/17/200713 Solution (5/7) - Strict demands for to hardware - –Activation by physical connection Activate software interface when input device connect to server –Once someone change connection, software interface does not activate until different A-info inputs to memory area in hardware. –Report device connection to client Client gets to know all cable-connected devices in server. –ID information (USB : venderID, ProductID) –Dynamically changing ID number (IEEE1394) physical Interface physical Interface Hardware for A-info Software Interface Server 2007/1/15 13:00.01 1394 @ hub 00 USB @ hub 00 activate

15. 01/17/200714 Solution (6/7) - Authentication mechanism adapted to live streaming (1/2) - –Sender sets A-info and report to client. To keep real-time data transmission, sender executes IP encapsulation with maximum amount of data that channel can transmit. data A-info A-info to infill this gap and report the A-info (settled by sender) to client for verification. Successive IP encapsulation execute from the top of memory area ． memory field that execute IP encapsulation （ sender application designates ） The gap happened between… ※ The periods physical interface transfer raw data from input device actually. ※ The periods sender application transfer data from software interface. Software Interface Hardware for A-info

16. 01/17/200715 Solution (7/7) - Authentication mechanism adapted to live streaming (2/2) - –Verification in the client Client should perform data execution and A-info verification at the same time. data A-info Real-time output of validation result. 2006/12/25.13:00.01 OK 2006/12/25.13:00.02 OK 2006/12/25.13:00.03 OK 2006/12/25.13:00.04 OK ・・・

17. 01/17/200716 DVTS implementation - Digital Video Transfer System - –IEEE1394 Simulated by modules using IEEE1394 device driver –Daemon process checking new hardware connection –Middleware issuing A-info between ieee1394.o and libraw1394.o –encryption of A-info using DES or AES –DV format DV sequence –150 DIF (Digital InterFace) blocks / 30fps –No-compression Successive IP encapsulation execute in sender. Extra step that transfers raw data to device (/dev/dv1394) in client. data IP/UDP A-info 1414bytes × 88frame374 + 1014 bytes × 1frame

18. 01/17/200717 Conclusions - Future work - –Mechanism that verifies no falsification in live communication Authentication Information embedding to the live streaming Software Interface & Additional hardware implementation Application for data frame creating and verification –Future work Implementation on DVTS (Linux) –IEEE 1394, DV-format (NTSC), No-compression –Consider hardware approach –Writing a paper