Implementation of Video Conference Applications based on JPEG ...

Download PDF
2 downloads 0 Views 219KB Size Report
Comment
In this paper we present an application of Video. Conference based on JPEG-GSM Codecs that incorporates security services. These Codecs have been.
Implementation of Video Conference Applications based on JPEG-GSM secure Codecs∗ L. Mengual, R. Caballero, J. Setién, J Yágüez DLSIIS, Facultad de Informática, U.P.M. Campus de Montegancedo s/n 28660, Boadilla del Monte (Madrid) Spain {lmengual, jsetien jyaguez}@fi.upm.es [email protected]

Abstract In this paper we present an application of Video Conference based on JPEG-GSM Codecs that incorporates security services. These Codecs have been developed using Java Media Framework (JMF) [1], an Application Programming Interface (API), developed by Sun. Our solution consists in encrypting frames coded with JPEG and GSM packets that are later encapsulated in packets of the RTP protocol [2] (Real Time Transport Protocol). Everything has been developed using the facilities provided by JMF, in particular, we have used the implementation and dynamic registration of new Codecs to which we have incorporated security mechanisms. Our proposal consists in the creation of JPEG-GSM Codecs with a confidentiality service that can be used through a dynamic registration process by user applications. Each data source (audio and video) are transmitted in different RTP sessions being reproduced in synchronized way in the receiver. Our cipher system is based on in the Blowfish algorithm [3] of the Cryptix [4] open source cryptographic software library. 1. INTRODUCTION Real Time Protocol (RTP) is a protocol based on IP networks that provides end-to-end network delivery services for the transmission of the real-time data [5]. RTP is network and transport-protocol independent, thought it is often used over UDP. RTP enables you identify the type of data being transmited, determines what order the packets of data should be presented in, and resolve the problem of synchronize media streams from different sources [6, 7, 8, 9]. RTP data packets are not guaranteed to arrive in the order that they were sent (in fact, they´re not guaranteed to arrived at all). It´s up to the receiver to reconstruct the sender´s packet sequence and detect lost packets using the information provided in the ∗

J. Bobadilla, E. Jiménez IA, Escuela Universitaria de Informática, U.P.M. Complejo Politécnico de Vallecas Km.7 de la Carretera de Valencia 28031 (Madrid) Spain {jbobi, ernes}@eui.upm.es packet header. While RTP does not provide any mechanism to ensure timely delivery or provide other quality of services guarantees, it is augmented by the protocol RTCP (RTP Control Protocol) [10]. It provides control and identification mechanisms for RTP transmissions and enables you to monitor the quality of the data distribution. The problem of the security in the communications over Internet (e-commerce, billing systems, bank information access, etc) [11, 12, 13] has extended to realtime communications. The necessity to protect multimedia data distributed over Internet makes it necessary to encrypt the audio/video flows transported by RTP packets. The objective is that the resulting flow allows its transmission and later reproduction in real time. It is therefore indispensable to choose a specific place to incorporate the cipher engine in the code of our multimedia application, as well as to choose an encryption algorithm fast enough to allow real time communications. Over the past few years, a collaborative effort in the network research community has produced a suite of tools for multimedia conferencing over the Internet [14, 15, 16]. However, some of these systems are not portables, the source code is unavailable or do not support IETF (Internet Engineering Task Force) protocols. Java Media Framework (JMF) is a versatile application programming interface (API) for incorporating time-based media into Java applications and therefore portable and independent of the underlying hardware. Any data that change meaningfully with respect to time can be characterized as time-based media. Such media data can be obtained from a variety of sources, such cameras, microphones etc. To send o receive a live media broadcast or conduct a Video

This work is supported partially by Science and Technology Ministry of Spain under the proyects: “A Multi-Agent System Architecture for the automatic and dynamic Implementation of security protocols (TIC2001-3376)” and “Open System of Multimedia Digital Presentation in Real Time (TIC2000-1734-C03-02)”

Conference over Internet or Intranet, you need to be able to receive and transmit media streams in real time. JMF uses RTP for receiving and transmiting media streams across the network. This way, JMF can: Play various multimedia files in a Java applet or application (The formats supported include AU, AVI, MIDI, MPEG, QuickTime, and WAV); play streaming media from the Internet; capture audio and video with your microphone and video camera; process time-based media and change the content-type format; transmit audio and video in realtime on the Internet; broadcast live radio or television programs.

depacketizes it to obtain a complete frame in format JPEG (codec JPEG) or GSM data (codec GSM). Our solution consists on encrypt the video/audio data before its incorporation to the RTP packets (see Fig. 1 and 2) JPEG FRAMES ENCRYPTED IN RTP PACKETS VIDEO

JPEG FRAMES

Native Encoder

JPEG FRAMES

Packetizer

DePacketizer

BLOWFISH CIPHER ENGINE

BLOWFISH CIPHER ENGINE

VIDEO

Native Decoder

SECURE JPEG CODEC

In this paper we present an application of Video Conference that has been developed based on secure JPEG-GSM Codecs using JMF. These Codecs are registered in a dynamic way using the facilities of JMF. Our solution incorporates a cipher engine based on the Blowfish algorithm, the fast enought to provide a real time transmission of the video/audio flow. 2 VIDEO CONFERENCE STRUCTURE

APPLICATION

The incorporation of security services to a Video Conference application, that has been developed with JMF, implies to encrypt the video/audio data that are transported by the network. This circumstance outlines several problems to solve: a first problem resides in the election of an encryption algorithm fast enought to guarantee the real time communications. Another problem resides in choosing the proper location of the cipher engine inside the JMF architecture of classes. Finally, a last problem and, that´s not trivial, is the distribution of the session key among the system users. Regarding the previous problems our alternative consist in, firstly, selecting the Blowfish algorithm as the responsible cipher engine. Blowfish is a symmetric block cipher of 64 bit block and uses a variable-length key, from 32 bits to 448 bits, fast enough to make the communication in real time possible. We decide to include the cipher engine in the classes that implement the selected video/audio codec: JPEG in the case of video data and GSM for the audio data. In particular, the location was the classes of the JMF architecture denominated "...packetizer/...depacketizer”, in the case of the JPEG Codec, and “...packetizer/ ..javadecoder” in the case of the GSM Codec. The “….packetizer” class is an implementation of the “BasicCodec” interface inside the architecture of classes and interfaces of JMF. This class encapsulates the JPEG/GSM data in RTP packets to be sent through the network. The class "...depacketizer" (in the case of JPEG) o “...javadecoder " (in the case of GSM) is invoked in the receiver. This class receives in a buffer RTP packets and

Figure 1. Secure JPEG CODEC in JMF GSM DATA ENCRYPTED IN RTP PACKETS AUDIO

GSM DATA

Native Encoder

GSM DATA

Packetizer

JavaDecoder

BLOWFISH CIPHER ENGINE

BLOWFISH CIPHER ENGINE

AUDIO

Native Decoder

SECURE GSM CODEC

Figure 2. Secure GSM CODEC in JMF The basic structure of our application is composed of the “SecureCustomTrans” class (see Fig. 3). This class from its method main obtains the session key in a secure way implementing a security protocol. Next it carries out the dynamic registration in the architecture JMF of the secure audio/video JPEG-GSM Codecs that we have implemented through “registerCustomPayload” method (see Fig. 4). Once registered the new Codecs, the start method of the “SecureCustomTrans” class invokes the methods and functions of the JMF API to establish the RTP session. public class SecureCustomTrans { static Format myJPEGFormat static Format myGSMFormat private byte[] key; --------------static boolean registerCustomPayload () {.....} private String createProcessors() { ...} private String createTransmitter() { ...} .................................................................................................. public static void main(String [] args) { java.security.Security.addProvider(new cryptix.provider.Cryptix()); security_protocol sp=new security_protocol (); Key = sp. Get_Key ; ----------------registerCustomPayload(); SecureCustomTrans sct = new SecureCustomTrans (..); String result =sct.start(); }//main }//SecureCustomTrans

Figure 3. SecureCustomTrans class pseudocode This way the “SecureCustomTrans” class creates two new classes: “CreateProcessor” and

“CreateTransmiter”. The first one creates what in JMF is called proccesor that is the entity in charge of managing the input signal, to choose the appropriate Codec and to return the encoded data. The second class takes charge basically of encapsulating the data that receives from the proccesor in RTP packets. static boolean registerCustomPayload () { RTPManager tempMgr = RTPManager.newInstance(); com. ibm.media. codec.video. jpegencrypted. Packetizer jpegPacketizer=null; try {jpegPacketizer=new ..video.jpegencrypted.Packetizer(key);} ……. try { PlugInManager.addPlugIn(jpegPacketizer.getClass().getName(), jpegPacketizer.getSupportedInputFormats(), JpegPacketizer.getSupportedOutputFormats(null), PlugInManager.CODEC); } myJPEGFormat = (jpegPacketizer.getSupportedOutputFormats(null))[0]; tempMgr.addFormat(myJPEGFormat, JPEG_ENCRYPTED_PAYLOAD); try {gsmPacketizer=new ...audio.gsmencrypted.Packetizer(key);} …….. try { PlugInManager.addPlugIn(jpegPacketizer.getClass().getName(), gsmPacketizer.getSupportedInputFormats(), gsmPacketizer.getSupportedOutputFormats(null), PlugInManager.CODEC); } myGSMFormat = (gsmPacketizer.getSupportedOutputFormats(null))[0]; tempMgr.addFormat(myGSMFormat, GSM_ENCRYPTED_PAYLOAD); } //registerCustomPayload

Figure 4. registerCustomPayload method pseudocode 2.1 Processors Implementation In the following pseudocode (see Fig. 5) we present part of the implementation of the video/audio processors: private String createProcessors() { DataSource videoDataSource; DataSource audioDataSource; try {videoDataSource = javax.media.Manager.createDataSource(videoLocator); } try { audioDataSource = javax.media.Manager.createDataSource(audioLocator); } videoProcessor = javax.media.Manager.createProcessor(videoDataSource); audioProcessor = javax.media.Manager.createProcessor(audioDataSource); TrackControl [] videoTracks = videoProcessor.getTrackControls(); TrackControl [] audioTracks = audioProcessor.getTrackControls(); .......................... Codec cadenaCodecsVideo[] = new Codec[2]; cadenaCodecsVideo[0] = new com.sun.media.codec.video.jpeg.NativeEncoder(); cadenaCodecsVideo[1]= new com.ibm.media.codec.video.jpegencrypted.Packetizer(); try{videoTracks[i].setCodecChain(cadenaCodecsVideo); .................................. Codec cadenaCodecsAudio[] = new Codec[2]; cadenaCodecsAudio[0] = new com.ibm.media.codec.audio.gsm.NativeEncoder(); cadenaCodecsAudio[1]= new com.ibm.media.codec.audio.gsmencrypted.Packetizer(); try{ audioTracks[i].setCodecChain(cadenaCodecsAudio)}; } // createProcessors

Figure 5. createProcessors method pseudocode According to the structure of JMF classes the input signal coming either from a video camera or a sound card should go first through the class "...NativeEncoder” to be coded in JPEG frames/ GSM data and, next, these data should go through the "...Packetizer” class to be

encrypted and packetized in RTP packets. Both classes ”..NativeEncoder " and "....Packetizer” derive of the same “BasicCodec” class although they have different functions. JMF doesn't assume this codecs linkage and, therefore, it is necessary to program it. This is carried out in the class "CreateProcessors" with the "setcodecchain" method of the “TrackControl” class that make it possible to access to all the individual tracks (see Fig. 5). 2.2 RTP packets transmission The transmission of RTP packets from by the JPEGGSM Codecs is perfeormed by the method "createTransmitter". As a consequence a “RTPManager” object for each one of the sessions RTP implied is created. In our case two sessions, one for video and one for audio are created. Finally the method "createSendStream" of the ”RTPManager” class sends the data using the RTP protocol (see Fig. 6). private String createTransmitter() { .......................... try { rtpMgrs[0] = RTPManager.newInstance(); rtpMgrs[1] = RTPManager.newInstance(); rtpMgrs[0].addFormat(myJPEGFormat, JPEG_ENCRYPTED_PAYLOAD); rtpMgrs[1].addFormat(myGSMFormat, GSM_ENCRYPTED_PAYLOAD); …………………………………. videoLocalAddr = new SessionAddress( InetAddress.getLocalHost(), videoPort); videoDestAddr = new SessionAddress( ipAddr, videoPort); audioLocalAddr = new SessionAddress( InetAddress.getLocalHost(), audioPort); audioDestAddr = new SessionAddress( ipAddr, audioPort); rtpMgrs[0].initialize( videoLocalAddr); rtpMgrs[1].initialize( audioLocalAddr); rtpMgrs[0].addTarget( videoDestAddr); rtpMgrs[1].addTarget( audioDestAddr); videoSendStream = rtpMgrs[0].createSendStream(videoDataOutput, 0); videoSendStream.start(); audioSendStream = rtpMgrs[1].createSendStream(audioDataOutput, 0); audioSendStream.start(); } } // createTransmitter

Figure 6. createTransmtiter method pseudocode 2.3 JPEG-GSM Codecs structure The "...jpegencrypted.Packetizer" object was created from the “SecureCustomTrans” class by the “registerCustomPayload” method by means of a constructor that receives as parameter a session key distributed by the security protocol. In this constructor the “CipherEngineCodec” object is created. Thist will be in charge of encrypting with the Blowfish algorithm the video data (see Fig. 6). The kernel of the Codec “…jpegencrypted.Packetizer” is the “process” method (see Fig. 7) that carries out the processing of the input signal through the “inbuf “object and it returns the encryption data through the “outBuf “object. In the same way, the kernel of the “...gsmencrypted.Packetizer” Codec is the process method (see Fig. 8) that carries out the processing of the

input signal through the inbuf object and it returns the encryption data through the outBuf object. public class Packetizer extends BasicCodec { static final JPEGFormat fJPEG = new JPEGFormat(); static String JPEG_ENCRYPTED = "jpegencrypted/rtp"; private MotorEncriptacionCODEC private byte[] mykey; public Packetizer (byte[] key) { inputFormats = new VideoFormat[] {new VideoFormat(VideoFormat.JPEG)}; outputFormats = new VideoFormat[] {new VideoFormat(JPEG_ENCRYPTED)}; mykey=key; MyCipherEngine =new CipherEngineCODEC(); } // Packetizer public synchronized int process(Buffer inBuffer, Buffer outBuffer){ …………………………………..……. byte [] inData = (byte[]) inBuffer.getData(); System.arraycopy(inData,offset + inBuffer.getOffset(),sincif,0,copyLength); byte[] cifin = MyCipherEngine.BlowfishCipher(sincif, mykey); System.arraycopy(cifin, 0,outData, 8, cifin.length); outBuffer.setLength(cifin.length + 8); outBuffer.setSequenceNumber(currentSeq++); outBuffer.setFormat(outputFormat); outData[0] = 0; outData[1] = (byte) (offset >> 16); outData[2] = (byte) (offset >> 8); outData[3] = (byte) (offset); outData[4] = (byte)decimation; outData[5] = (byte)qfactor; outData[6] = (byte)(size.width/8); outData[7] = (byte)(size.height/8); }// process } // Packetizer

Figure 7. “...jpeg.packetizer “ class pseudocode public class Packetizer extends AudioPacketizer { private MotorEncriptacionCODEC mec; private byte[] myclave; public Packetizer (byte[] clave) { ……… super.supportedInputFormats = (new AudioFormat[] { new AudioFormat("gsm", 8000D, -1, 1, -1, -1, 264, -1D, Format.byteArray) }); super.defaultOutputFormats = (new AudioFormat[] { new AudioFormat("gsmencrypted/rtp", 8000D, -1, 1, -1, -1, 264, -1D, Format.byteArray) }); super.PLUGIN_NAME = "GSM cifrado Packetizer"; mykey=key; MyCipherEngine = new CipherEngineCODEC (); } // Packetizer public synchronized int process(Buffer inbuf, Buffer outbuf){ ..................................... byte abyte0[] = (byte[])inbuf.getData(); ……. .System.arraycopy(abyte0, inbuf.getOffset(), sincif, historyLength, result); byte[] cifrado = MyCipherEngine.BlowfishCipher(sincif, mykey); tamanoPaqueteCifrado = cifrado.length; abyte1 = validateByteArraySize(outbuf, tamanoPaqueteCifrado); System.arraycopy(cifrado,0,abyte1,0,tamanoPaqueteCifrado); ....................................... updateOutput(outbuf, super.outputFormat, tamanoPaqueteCifrado, 0); .............................................. } // process } // Packetizer

Figure 8. “...gsm.packetizer “ class pseudocode 3

CONCLUSIONS

In this work we have present the implementation of a secure system of Video Conference using the JMF API. Among all the choices we decided to use the facilities provided by JMF to implement and register Codecs that fit the requirements of the applications. In particular, our solution is based on the implementation of two secure JPEG-GSM Codecs that make it posssible to encrypt

JPEG-GSM data before their encapsulation as RTP packets. Our contribution is that we have established where to locate the cipher engine to get a encrypted transmission of high quality, in real and synchronized time. The Video Conference system that we present in this paper has been proven in an environment of Local Area Network, as well as in a point to point connection with FrameRelay obtaining delay that is less than 0.5s 4

REFERENCES

[1] http://java.sun.com/products/java-media/jmf/. [2] Schulzrinne, H, Casner, S., Frederick, R., Jacobson, V. (Audio-video Transport working group) “RTP: A Transport Protocol for Real-Time Applications”, RFC 1889, January 1996. [3] Schneier B. “Description of a New Variable-length Key, 64Bit Block Cipher (Blowfish).”, Cambridge Security Workshop Proceedings Springer-Verlag, 1994. [4] http://www.cryptix.com/ [5] Leon García, A., Widjaja, I. “Conmunication Networks” McGraw-Hill, 2001 [6] Norden, S., Manimaran, G. and Siva Ram Murthy, C. “Dynamic planning based protocols for real-time communication in LAN and switched LAN environments”, Computer Communications, Volume 24, Issue 13, 15 August 2001, Pages 1256-1271 [7] Huang, C., Kung H., and Yang, J. “Synchronization and flow adaptation schemes for reliable multiple-stream transmission in multimedia presentations”, Journal of Systems and Software, V. 56, Issue 2, 1 March 2001, Pages 133-151. [8] Vandalore, B., Feng W., Jain, R. Fahmy, S. “A survey of Application Layer Techniques for adaptive Streaming of Multimedia”, Real Time Imaging 7, 2001, Pages 221-235. [9] Ahmed, T., Buridant, G., Mehaoua, A. “Management of Multimedia Traffic Streaming II - Delivering of MPEG-4 Multimedia Content over Next Generation Internet”, Lecture Notes in Computer Science, 2001 – V. 2216. Pag. 110– 127 [10]Brown, K. “The RTCP gateway: scaling real-time control bandwidth for wireless networks, Computer Communications”, Volume 23, Issues 14-15, 30 August 2000, Pages 1470-1483. [11]Romao, A., Da Silva, M., Silva, A. “Secure electronic payments based on mobile agents”, Distributed and Parallel Databases, V. 8, Issue 4, October 2000, Pages 447-470. [12]Jansen, W. A. “Countermeasures for mobile agent security”, Computer Communications, volume 23, Issue. 17, 1 November 2000, Pages 1667-1676. [13]Ashley P., Vandenwauver M., Siebenlist F. “Applying authorization to intranets: architectures, issues and APIs”. Computers Comunications, Vol. 23, Nº 17, November 2000. [14]Jacobson V., Mccanne S. LBL Whiteboard. Lawrence Berkeley Laboratory. (ftp://ftp.ee.lbl.gov/conferencing/vic) [15]Rowe, L. McCanne S, Open Mash consortium http://www.openmash.org/about/index.html [16]Turletti T. The INRIA videoconferencing system (IVS). ConeXions 8,10 (Oct. 1994), 20-24