the design and the security concept of a collaborative whiteboard

The design and the security concept of a collaborative whiteboard

W. Geyer* , R. Weis

Praktische Informatik IV, University of Mannheim, L 15, 16, D-68131 Mannheim, Germany

Abstract

This paper presents the design and the security concept of the digital lecture board, an enhanced whiteboard tailored to the specific needs ofcollaborative types of work, for instance, in computer-based distance education. The development of the digital lecture board emerged fromour experiences with synchronous, computer-based distance education in the TeleTeaching projects of the University of Mannheim. Foralmost four years, we have been using video conferencing tools for transmitting lectures and seminars. These tools prove to be far fromoptimal for this purpose since they are not powerful enough to support team work, not flexible enough for the use of media, and somewhatdifficult to handle for non-experts. Security issues such as authentication, secure key exchange, and fast symmetric encryption are almostcompletely neglected, even though security is extremely important to allow for confidential, private sessions, and billing. We discussshortcomings of existing video conferencing tools and describe features we had in mind while designing the digital lecture board. Wethen present our security concept that is a user-oriented approach that takes into account the specific security requirements of different usergroups. We also cover implementation issues of the current prototype.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Video conferencing; Whiteboard; Cyptography; Open PGP; CSCW; Teleteaching

1. Introduction

Computer-based video conferencing is one of today’smost exciting multimedia applications. Powerful hardwareand advances in communication technology have enabledthe synchronous transmission of audio and video even overlow-bandwidth networks, such as ISDN, in an acceptablequality. Typically, video conferencing systems cometogether with a whiteboard for joint sketching of ideas,and/or an application-sharing tool. Besides the usage inpure teleconferencing scenarios, these systems areemployed in a variety of application fields such as distanceeducation, teleconsulting, telemedicine, telecooperation etc.Most of these advanced application fields impose a highdemand on additional functionality that is not satisfied byexisting video conferencing software. Specifically, mostsystems do not provide secure data delivery or accounting;collaborative types of work are not supported adequatelyand media usage is very limited.

The shared whiteboard is often the core component ofthese systems since it is used to transmit additional contents(e.g. slides) besides audio and video. In this paper, wepresent a novel whiteboard—called thedigital lectureboard (dlb)—which is being developed in the context ofcomputer-based distance education, i.e. the whiteboard

takes into account the specific requirements of synchronousteaching and learning in higher education, continuouseducation or corporate education [11]. The development ofthe dlb was motivated by the experiences we gathered in theTeleTeaching projects of the University of Mannheim where,for almost four years, lectures and seminars have been trans-mitted using standard video conferencing tools [8].

This paper is structured as follows: after a brief survey ofrelated work in the field of secure whiteboards, we givesome insights into the teleteaching activities of the Univer-sity of Mannheim. In Section 4 we discuss shortcomings ofexisting video conferencing tools and describe features wehad in mind while designing the dlb. We then present oursecurity concept, which is a user-oriented approach thattakes into account the specific security requirements ofdifferent user groups. The last chapter covers implementa-tion issues of the current prototype.

2. Related work

Many existing video conferencing systems such asNetMeeting, CUSeeMe, Pro-Share, or PictureTel provideaudio, video, application sharing, and standard whiteboardfeatures but consider neither security issues nor the specificrequirements of collaborative types of work, such asreference pointing, raising hands, forming work groups,controlling the course of instruction etc. The MBone tools

Computer Communications 23 (2000) 233–241

0140-3664/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0140-3664(99)00177-2

www.elsevier.com/locate/comcom

* Corresponding author.E-mail address:[email protected] (W. Geyer).

vic (video conferencing tool), vat (visual audio tool), andwb (whiteboard) actually support security but only weakDES encryption [33]. Due to export regulations, applica-tions using DES encryption cannot be downloaded legallyfrom the US.

For the platform-independent whiteboard TeleDraw [43],which is being developed in the context of the MERCIproject [36], it is planned to include MERCI securityenhancements; the current version is still insecure. SinceTeleDraw has been designed for video conferencing, italso fails to consider requirements of collaborative work.

Security within the MERCI project is basically realized bythe Secure Conferencing User Agent (SCUA), developed byGMD [15]. SCUA is an e-mail-based approach, which allowsto initiate conferences securely using Privacy Enhanced Mail(PEM). For the actual transmission of data, SCUArelies on thebuilt-in weak security mechanisms of the MBone tools. Afterkey exchange by e-mail, the tools have to be started with thesession key as a command line parameter or the key has tobe introduced manually during runtime.

The following two projects focus on the specific needs ofteleteaching but do not consider security issues: The“Authority on the Fly” (AOF) concept [3] merges broad-casting of lectures with authoring of Computer-based Train-ing (CBT) software. With AOF, lectures are transmitted bymeans of an extended whiteboard to a number of receivers.Interactivity is limited to audio and video, the whiteboardhas no back channel. Thus, collaborative types of instructionare not supported.

The Interactive Remote Instruction (IRI) system devel-oped at Old Dominion University [34] is a very powerful,integrated teaching and learning environment. The systemallows to view or make multimedia class presentations, totake notes in a notebook, and to interact via audio/video andshared tools (by means of an application sharing tool). IRIalso provides class management and floor control functions.Floor control regulates the concurrent access to sharedresources (e.g. an audio channel). The system differs fromours in that IRI partly relies on analog transmission ofNTSC video signals. Collaboration is limited to applica-tion sharing and the secure transmission of data is notsupported.

3. Background

The dlb is being developed in the context of the Tele-Teaching project of the University of Mannheim [8]. Theproject aims at an improvement in the quality and quantityof teaching and learning by using multimedia technologyand high speed networks for the distribution of lectures andseminars. We have implemented three different instruc-tional settings that are characterized by their scope of distri-bution, interactivity, and individualization of the learningprocess as indicated in Fig. 1. For a detailed description ofpedagogical, organizational, and technical issues of theproject refer to Refs. [8,10].

In the Remote Lecture Room(RLR) scenario, largelecture rooms, equipped with audio/video facilities, areconnected via high speed networks, and courses areexchanged synchronously and interactively between parti-cipating institutions.Remote Interactive Seminars(RIS)describe a more interactive type of instruction. Small groupsof participants are distributed across few seminar rooms,which are also connected by a network. The focus of RISis the cooperative, online construction and presentation ofreports. TheInteractive Home Learning(IHL) scenarioaims at a maximization of the distribution degree of allclass participants. Each student learns asynchronously aswell as synchronously at home in front of his or her PC.Apparently, IHL makes the greatest demands on pedagogy(e.g. controlling the course of instruction and human inter-action) and technology (e.g. transmission of audio and videoin high quality over low-bandwidth links).

We use the Internet and the MBone video conferen-cing tools vic, vat, and wb for remote lecturing. Ourexperiences during the last four years indicate that thesetools can provide satisfactory results if the lectureradapts the layout of the lecture exactly to the limitedfeatures of the software. However, these tools are farfrom optimal for teleteaching since they have not beendesigned for this purpose. This concerns specifically theelectronic whiteboard, which can be considered a substitutefor the traditional blackboard or the overhead projector. Alongwith audio, the whiteboard is most important for conveyingknowledge to distributed participants. In order to overcomethe weaknesses of the whiteboard, we decided to develop thedlb, which will better satisfy the needs of computer-basedteaching and learning.

4. Design issues of the digital lecture board

In this section, we present, in more detail, the shortcomingsof the existing MBone tools,1 and we discuss the mostimportant features we had in mind while designing the dlb.

W. Geyer, R. Weis / Computer Communications 23 (2000) 233–241234

Fig. 1. Instructional settings.

1 The described shortcomings also more or less concern other videoconferencing systems such as NetMeeting, CuSeeMee etc.

4.1. User interface

The MBone tools do not provide an integrated user inter-face. Teachers and students complained about many confus-ing windows and control panels which are not important forremote instruction but make it more difficult to operate thetools. Since computer-based distance education should notbe restricted to computer experts, we find it especiallyimportant that the dlb provides an easy-to-operate user inter-face, which also integrates audio and video communication.In order to allow the interface to adapt to different instruc-tional settings, it should be configurable. RLR, for instance,mainly focuses on the presentation of knowledge to passivereceivers who thus do not want to see tool or page selectingoptions on their screens.

4.2. Media usage and handling

One of the most limiting factors of the MBone white-board is media usage and handling: only postscript andplain ASCII text are supported as external input formats,and editing of the built-in graphic and text objects is notpossible neither for any member of the group nor for thegenerator. Since media are very important in moderninstruction [18], the dlb should support a variety of mediaformats (GIF, HTML, AIFF, MPEG etc.) as well as manybuilt-in object types (lines, rectangles, circles, text etc.).Objects must be editable by every participant, and the dlbshould provide functions like select, cut, copy, paste, group,raise, lower, etc. similar to a word or graphic processingsoftware.

4.3. Workspace paradigm

The shared workspace of wb is limited to a two-layerconcept with a postscript slide in the background and draw-ings and text in the foreground. It is, for instance, not pos-sible to render two different postscript slides onto a singlepage so that results of two distributed work groups may becompared. Moreover, participants cannot have a privateworkspace where they can prepare materials, for instance,when doing online group work. Modern telecooperationsoftware requires a more flexible workspace concept withmultiple layers where arbitrary media objects (audio, video,images, animations etc.) can be displayed, grouped, raised,lowered etc. Single participants or small groups should beoffered private workspaces (invisible to the rest of thegroup) in order to allow for modern types of instructionsuch as group work. The outcome of the group work canbe transferred to the shared workspace so as to allow a widerdiscussion of the results.

4.4. Collaborative services

Today’s video conferencing systems suffer a lack ofcommunication channels compared to the traditional face-to-face situation. Social protocols or rules, which control the

human interaction and the course of instruction in a class-room, are not automatically available in a remote situationand are difficult to reproduce. These mechanisms include,for instance, raising hands, giving the right to talk or to writeon the black board, setting up work groups, and referencepointing. Collaborative services provide mechanisms tosupport the communication of persons through computersand to increase social awareness. In this sense, collaborativeservices provide an electronic surrogate to compensate asfar as possible for the lack of inter-personal communicationchannels. Basic services such as floor control, sessioncontrol, telepointers, or voting should be supported by thedlb.

Floor control realizes concurrency control for interactive,synchronous cooperation between people by using the meta-phor of afloor. A floor is basically the temporary permissionto access and manipulate shared resources (e.g. a shareddrawing area). Session control denotes the administrationof multiple sessions with their participants and media.Session control increases social awareness in distributedwork groups because members gain knowledge of eachother and their status in the session. Telepointers aremouse pointers or cursors that are visible by all participantsin a session. A telepointer can be used to create a commonpoint of reference in the communication. Voting allows foran additional feedback by polling opinions about certainsession criteria (e.g. presentation quality). A detailed analy-sis of collaborative requirements in teleteaching for the dlbcan be found in Ref. [13].

4.5. Synchronized recording and playback of sessions

The dlb should also provide the possibility to record atransmitted lecture or course, including all the mediastreams (audio, video, whiteboard actions and media, tele-pointers etc.). Students will then be able to retrieve thelecture in order to review certain topics or the completelecture if they have missed it. In order to achieve a synchro-nized recording, data has to be time-stamped. The datastreams could then be recorded by existing systems likethe Video Conference Recording on Demand (VCRoD)service [16] or the multicast Media-on-Demand (mMOD)system [38]. These systems rely on the Real-Time TransportProtocol RTP for synchronized recording [40]. The currentrelease of the MBone whiteboard wb does not implementthe RTP standard.

4.6. Storage and retrieval of pages and teaching materials

Lectures or courses given with the computer need to beprepared in advance, i.e. slides, images, animations etc.have to be produced. The preparation of materials withthe MBone whiteboard wb is limited to a list of postscriptfiles which can be imported by mouse click during a session.In order to allow for better preparation of online lectures andfor saving results after a lecture, the dlb should supportstorage and retrieval of pages and objects in a structured,

W. Geyer, R. Weis / Computer Communications 23 (2000) 233–241 235

standardized file format such as SGML or SMIL [52]. More-over, it would also be desirable for the dlb to have access toa multimedia database which stores teaching and learningmaterials of teachers and students. Such databases are also aresearch issue in our TeleTeaching project (see Refs.[8,14]).

5. Security concept

The exponential growth of the Internet in recent years hasfostered the importance of secure communication. Securityhas become a major research task in computer science.Especially for commercial applications, security in theInternet is a “conditio sine qua non”.

5.1. State-of-the-art

The well-known DES encryption algorithm, which wasoriginally designed for confidential, not-classified data, isused in many applications today (e.g. electronic banking).The MBone whiteboard wb also relies on DES for encryp-tion. Several brute force attacks have disclosed the weak-nesses of DES, which indicates that the key length forsymmetrical algorithms should be at least 75–90 bits [4].

DES was originally developed for the hardware of theseventies and not optimized for fast software encryption.Many multimedia applications today demand high perfor-mance that cannot be satisfied by DES software encryption.In recent years, novel algorithms that perform better but aresimilar to the DES scheme have been developed [45]. Someof these algorithms have even been specifically designed forfast software encryption on modern processor generations.

Due to export restrictions of the US government, exportversions of many software products have the DES encodingdisabled. Hence, outside the US, the DES encryption featureof wb cannot be used legally. Moreover, the source code ofwb is not publicly available which inhibits the evaluation ormodification of the cryptographic implementation.

These security limitations of the MBone whiteboard wbhave stimulated the integration of modern encryption algo-rithms into the dlb so as to provide secure video conferen-cing with a powerful, collaborative whiteboard outside theUS as well.

5.2. Security requirements

Besides the functional requirements described inSection 4, a secure dlb has to satisfy the following securityrequirements:

• Fast symmetric encryptionfor the secure transmission ofconfidential whiteboard data. Data streams will beencrypted by use of a session key.

• Flexibility for different user groupswith differentrequirements concerning legal issues, costs, level ofsecurity, and performance.

• Strong and flexible public key cryptographyallows forauthentication and automated, secure exchange ofsession keys.

• Light-weight payment protocolsare required for the auto-mated billing of telecourses and teleseminars which areoffered by educational institutes or by companies. Sincethe group of session participants may be rather large andthe amounts paid rather small, we prefer light-weightprotocols with minimal overhead.

• New voting schemesfor light-weight and secure voting ina session. Voting as a collaborative service adds to adistributed group an addition communication channelwhich increases social awareness (see Section 3).

5.3. User-oriented cryptography

The dlb uses a flexible user-oriented security concept thatcan be adapted to different user requirements. Users maychoose from predefined security profiles or even customizetheir own security requirements. The choice may be driven,for instance, by legal issues, costs, required level of security,and performance. We identify the following main profiles oruser groups:public research, financial services, and inno-vative companies(see Table 1).

Since users who work in thepublic researchoften benefitfrom license-free employment of patented algorithms, werely on theIDEA cipher [21]. The algorithm has a strongmathematical foundation and resists differential cryptoana-lysis well [22]. The key length of 128 bits immunizesagainst brute force attacks. IDEA was the preferred cipherin the Pretty Good Privacy (PGP) versions until 2.63.However, commercial users have to pay license fees.

In thefinancial servicesbusiness we find a strong prefer-ence for DES-based systems. Since DES has been crackedby brute force attacks, we suggest the usage ofTriple-DES,DESXor DES2X [29] in this application field. In addition tothe fact that Triple-DES performs poorly, it also does notprovide the same level of security as IDEA. Recent work byLucks showed that the effective key length for exhaustivesearch attacks can be reduced to 108 bits [28] while stillmaintaining immunity against brute force attacks. Acheaper method to avoid brute force attacks on DES iswhitening. With one key-dependent permutation beforeand after the DES encryption, exhaustive key search is


Table 1Predefined security profiles

Profile Public key Secret key Hash

Public research Rabin IDEA RIPEMD-160Financial services RSA Triple-DES RIPEMD-160Innovative companies Rabin CAST RIPEMD-160PGP 2.63i RSA IDEA MD5PGP 5.x DLP CAST SHA-1GPG DLP Blowfish RIPEMD-160

provably not feasible. RSA Data Security Inc. uses thisprocedure under the name DESX [19] in their toolkitBSAFE. In addition, we have implemented DES2X [29],which combines whitening and double encryption. Itseems that DES2X is more secure and faster than Triple-DES.

For innovative companiesthat are not afraid of new algo-rithms, we use the novel, license-free algorithmCAST.CAST is a very fast DES-like Feistel-cipher designed byCarlisle Adams and Stafford Tavares. The system has rathergood resistance to differential cryptoanalysis, linear cryp-toanalysis, and related-key cryptoanalysis. The CAST-128[1] implementation uses 128 bit keys. CAST possesses anumber of other desirable cryptographic advantagescompared to DES, e.g. no complementation property andan absence of weak and semi-weak keys. CAST is thepreferred cipher in the PGP-Versions 5.x.

In addition to these predefined user profiles, we haveimplemented options for full compatibility toPGP 2.63i,PGP 5.x and GPG (GNU Privacy Guard) [20]. GPG(formally known as G10) is a free PGP replacementwhich does not rely on patented algorithms. GPG prefersBlowfish[41] as symmetrical algorithm. Blowfish is one ofthe fastest secure block ciphers. It was designed by BruceSchneier with a key length variable up to 448 bit. We use akey length of 128 bit. We use a key length of 128 bit assuggested in the Open PGP standard [6].

Moreover, we have also integrated the fast AdvancedEncryption Standard (AES) candidate.Twofish [42] andRijndael [7]. AES is the upcoming successor of DES.Twofish and Rijndael work on 128 bit block sizes andsupport key lengths of 128, 192, and 256 bits. Note thatwe do not support any weak ciphers like in S/MIME.

For authentication and to simplify the key exchange, weuse asymmetric cryptography. In addition toRSA, we offersignature and key exchange procedures based on theDiscrete Logarithm Problem(ElGamal/DSA) in order toavoid problems with US patents. We have also includedRabin’sscheme for key exchange and signatures. Rabin’sscheme achieves security through the difficulty of findingsquare roots modulo a composite number, which is equiva-lent to factorization. Due to this fact, Rabin’s scheme isprovablyat least as secure as RSA. The Rabin encryptionneeds only one modular squaring which provides fasterencryption than in RSA. After decryption of the sessionkey, we get four possible results. Using a specific paddingdesigned by Weis and Lucks, we can easily find the right

result. This scheme (Fig. 2) improves cryptographic securityand strengthens Rabin against several attacks [50].

As innovative algorithms, we further implement ElGamalprocedures overelliptic curves[17]. These cryptosystemsare assumed to provide the same security as the RSAscheme discussed while operating with a shorter key length.This allows, for instance, for shorter signatures, reducedcommunication, less storage space, and faster computation.

5.4. Research issues

5.4.1. Fast multimedia encryptionAll the algorithms presented are well tested and state-of-

the-art in cryptography. Nevertheless, we are alsodeveloping new algorithms for fast software encryption ofcontinuous multimedia streams. A very interesting idea is touseLuby-Rackoff[24] ciphers. Unbalanced constructions ofthese ciphers can operate very fast on large block sizes [25].Anderson and Biham have proposed two fast block ciphers:Lion andBEAR[2]. The fastest new algorithm in this class isBlock Encryption Algorithm with Shortcut in the Thirdround (BEAST) [26].

BEAST is assembled from hash-based Message Authen-tication Codes (MACs) and stream ciphers and it isprovablysecure if these building blocks are secure. The performanceis very good when operating on large block sizes. We havetested different versions of BEAST in a real application forthe first time [49].

5.4.2. Light-weight paymentBased on encrypted communication, it is rather easy to

implement light-weight payment protocols. After the trans-mission of an electronic coin, the current session key—encrypted with the public key of the client (payer)—istransmitted. This method of separating encrypted multi-cast/broadcast transmission of the bulk data and the keytransmission can be found in many distributed multimediasystems. Since for much of the information on the Internetonly small and inexpensive payments are acceptable, somelight-weight payment systems have been developed.

The Payword system proposed by Rivest and Shamirseems to be most suitable [39]. Payword uses the valuesof a hash chain as coins. This idea can also be found inthe S/Key-protocol of Lamport [23]. The cost of therequired calculations is very low. Even the frequentlyrequired verification of a payment needs only one hash.According to Rivest and Shamir, the calculation of a hashfunction is up to ten thousand times faster than public keyoperations. Therefore, we will rely on the payword schemefor billing multimedia applications.

5.4.3. Remotely keyed encryption protocolsAt the moment smartcards are the only practicable

pretty secure place to store secret keys. Although inthe last few years some interesting cryptographic [44]and many very dangerous hardware attacks [48] have


Fig. 2. Simple scheme of redundant use of random oracles [51].

been conducted, smartcards can provide a higher secur-ity level than other storage systems. Nevertheless, thephysical properties (e.g. 8 bit processors) restrict theencryption bandwidth [31]. New “remotely keyedencryption” protocols [5] support fast encryption onslow smart cards. We are working on the integrationof some protocols developed recently at the Universityof Mannheim called RaMaRK [27,32], ImprovedRaMaRK [46] and ARKE [30].

5.4.4. Voting schemesThe implementation of secure election and voting as a

collaboration service is subject to current research [47].One idea is to build a “Virtual Hyde Park” where the parti-cipants can decide in a confidential vote who should managethe floor. So far, no light-weight, group-oriented, and securevoting schemes are known.

6. Implementation

6.1. Status of development

The prototype implementation of the dlb already includes

most of the features mentioned in Section 4 as well as thesecurity concept described in Section 5. We do not haveintegrated audio and video communication yet; the interfaceto our VCRoD system is in preparation. To ensure a highdegree of portability, we implemented the prototype inC11 and the Tcl/Tk scripting language [37], and tookgreat care to reuse only components, which are availableon all major platforms (e.g. ghostscript or the image libraryImageMagick). The current version 1.8 is available for theUnix systems IRIX, Solaris, and Linux. Fig. 3 shows ascreen shot of dlb’s user interface which has been designedaccording to the look & feel of common Windowsapplications.

The shared workspace of the dlb provides the commoncontext for group work. The dlb adheres to the relaxed WhatYou See Is What I See (WYSIWIS) paradigm. Basicallyevery participant can operate its dlb autonomously, i.e. inparallel to other participants; actions on the shared work-space (drawing, pointing etc.) are generally visible to allparticipants. In Fig. 3, for instance, the workspace containsa postscript slide that has been annotated with graphicalobjects.

The page selection utility provides access to the pagesof an online document. The pages can be accessed directly


Fig. 3. User interface of the dlb.

through a global and local page list. Page changingoperations are basically visible to all participants as longas theLive button is enabled. Otherwise, all whiteboardactions are executed locally and no longer transmitted tothe group. This provides a private workspace whereusers can prepare materials invisible to the rest of thegroup. Private material (pages and drawings) can be trans-mitted to the group by enabling theLive button.

The page selection utility also allows switching to theannotation mode, which enables users to attach privateannotations to the online document. Private annotationsare never transmitted to the group. Moreover, the pageselection utility provides access to the available telepoin-ters. The dlb automatically chooses a telepointer color notbeing used by other participants.

The current page, the total number of pages and thecurrent zoom factor are displayed below the shared work-space . Moreover, the user is provided with buttons forflipping pages locally, i.e. independently of the selectedmode (Live/Annotation). The status line is used todisplay additional user information such as error messages.

The participant window contains a list of the partici-pants currently involved in the online session. By clickingon the participants’ names, the user can get details—e-mail

address, telephone number etc. The participant informationis based on RTCP session messages [40].

The icon bars and allow quick access to the mostimportant functions of the dlb, for instance, file access to dlbdocuments, editing functions (cut, copy, paste, undo), func-tions for changing the properties of existing objects or forcreating new text, graphic or media objects.

Most of the described functions of the dlb can be accessedthrough the dlb’s menu bar . Additionally, the user inter-face can be configured through theViewmenu. For presen-tation purposes, for instance, the interface can be reduced tothe shared workspace only. Moreover, participants are ableto fit the visible workspace to their screen size by zooming.Grid lines can be used to ease construction of graphicalobjects.

TheInsertmenu allows us to import external media (pixelimages, postscript, text and windows). Via theTool menuadditional communication channels, which increase thesocial awareness during a session, can be controlled andconfigured. The dlb currently supports the following colla-borative services: telepointers, voting, online-feedback [47],raising hands, and chat. Most configuration options can beedited and stored through theOptionsmenu. This menu alsoprovides comfortable access to the security featuresdescribed in this paper. Fig. 4 depicts the dialogs for theselection of security profiles and for the customized config-uration of security options. Note that all choices provide alarge margin of safety.

6.2. Secure communication

The security concept described in Section 5 is integrateddirectly into the dlb as indicated in Fig. 5 (OPGP layer). Wehave implemented a security library that includes the cryp-tographic algorithms and protocols discussed in the previoussection. The library provides full compatibility with theOpen-PGP (OPGP) standard [6]. OPGP is an open Internetstandard that is compatible to the defacto standardPrettyGood Privacy.

The Whiteboard Transfer Protocol (WTP) is the applica-tion protocol of the dlb. WTP defines packet formats andsemantics for creating graphical objects or pages, for tele-pointer data etc. WTP packets are the payloads of RTPpackets. RTP has been used for several reasons: first, RTPpackets contain time stamps, which allow for synchroniza-tion with other RTP-compatible data streams (e.g. audio,video). Second, RTP provides light-weight session controlthrough RTCP. Third, existing MBone recording systemsrely on RTP.

The OPGP layer realizes the encryption/decryption of thetransmitted data, i.e. RTP packets are wrapped into OPGPpackets. We then use either unreliable UDP connections(e.g. for telepointers) or reliable SMP connections to trans-mit the OPGP packets. Scalable Multicast Protocol (SMP) isa reliable transport service developed in the context of thedlb project [12].


Fig. 4. Security dialogs.

Fig. 5. Protocol stack of the dlb.

OPGP allows for the standardized encrypted or unen-crypted transmission of data. The complete encapsulationof RTP packets in OPGP packets has the following advan-tages:

• OPGP header information can be used to identifywhether or not data have been encrypted. RTP suggestschecking merely the header validity to recognizeencrypted data. Thus, if we would use only RTP for thesecure data transmission, encrypted packets could not berecognized unambiguous.

• The encryption of complete RTP packets also protectsdata in the RTP headers, e.g. participant information inRTCP headers.

The obvious disadvantage of this approach is the use ofstandardized RTP multiplexers, mixers, or gateways thatrely on RTP header information to accomplish their services(e.g. media scaling). A possible solution would be theimplementation of OPGP within such gateways such thatthe gateway will be able to read RTP header data. SinceOPGP supports “partial” decryption, the gateway need notdecrypt the complete data packet.

7. Conclusion and future work

Our experience with computer-based distance educationin the TeleTeaching projects of the University of Mannheimindicates that standard video conferencing systems are farfrom optimal for collaborative types of instruction or work.Further, they almost completely neglect security issues. As aconsequence, we have developed the dlb presented in thispaper. The dlb is an integrated, extended whiteboard toolthat is tailored to the specific needs of computer-baseddistance education, but also integrates state-of-the-art secur-ity mechanisms. The dlb can also be employed for highlysecure video conferencing with extended demands on colla-boration and media flexibility.

The dlb prototype implementation presented in this paperhas already been successfully employed for a teleseminarconsisting of 12 sessions [9]. Preliminary evaluation resultsindicate a very high acceptance by teachers and students.From a technical point of view, the dlb proved to be verystable since at no time did software errors force us to inter-rupt the teleseminar.

Future research directions include distributed animationsfor the dlb based on a new scripting language, light-weightpayment protocols and a novel secure voting scheme. Wealso intend to provide a Windows version of the dlb verysoon to further improve its acceptance.

Acknowledgements

The authors would like to thank Prof Wolfgang Effels-berg and Dr Stefan Lucks for their helpful comments and the

interesting discussions. We also would like to expressthanks to the anonymous reviewers for the useful remarks.

References

[1] C. Adams, The CAST-128 Encryption Algorithm, Internet RFC2144,May 1997.

[2] R. Anderson, E. Biham, Two practical and provable secure blockci-phers: BEAR and LION, in: D. Gollmann (Ed.), Proc. Fast SoftwareEncryption, Lecture Notes in Computer Science, 1039, Springer,Berlin, 1996.

[3] C. Bacher, T. Ottmann, Tools and services for authoring on the fly,Proc. ED-MEDIA’96, Boston 1996.

[4] M. Blaze, W. Diffie, R. Rivest, B. Schneier, T. Shimomura, E.Thompson, M. Wiener, Minimal key lengths for symmetric ciphersto provide adequate commercial security, A report by an ad hocgroup of cryptographers and computer scientists, URL: http://www.counterpane.com/keylength.html, January 1996.

[5] M. Blaze, High-bandwidth encryption with low-bandwidth smart-cards, in: D. Gollmann (Ed.), Proc. Fast Software Encryption, LectureNotes in Computer Science, 1039, Springer, Berlin, 1996, pp. 33–40.

[6] J. Callas, L. Donnerhacke, H. Finnley, OP Formats-OpenPGPMessage Format, Internet Draft, November 1997.

[7] J. Daemen, V. Rijmen, AES Proposal: Rijndael, NIST AES Proposal,June 1998.

[8] A. Eckert, W. Geyer, W. Effelsberg, A distance learning system forhigher education based on telecommunications and multimedia—acompound organizational, pedagogical, and technical approach, Proc.ED-MEDIA’97, Calgary, June 1997.

[9] W. Effelsberg, W. Muller, W. Stucky, D. Basin, H. Schmeck, L. Vigano,W. Weitz, D. Merkle, R. Weis, W. Geyer, Sicherheit in der Kommuni-kationstechnik, Teleseminar WS 1998/99, URL: http://www.iig.uni-freiburg.de/telematik/veranstaltungen/telesem.html, 1998.

[10] W. Geyer, A. Eckert, W. Effelsberg, Multimedia in der Hochschul-lehre—TeleTeaching an den Universita¨ten Mannheim and Heidel-berg, Studieren und weiterbilden mit Multimedia, ReiheMultimediales Lernen in der Berufsbildung, BW Bildung und WissenVerlag, Nurnberg, 1998 in German.

[11] W. Geyer, W. Effelsberg, The digital lecture board—a teaching andlearning tool for remote instruction in higher education, Proc. ED-MEDIA’98, Freiburg, June 1998.

[12] M. Grumann, Entwurf und Implementierung eines zuverla¨ssigenMulticast-Protokolls zur Untersu¨tzung sicherer Gruppenkommunika-tion in einer Teleteaching-Umgebung, Master’s thesis (in German),Lehrstuhl Praktische Informatik IV, University of Mannheim, 1997.

[13] V. Hilt, W. Geyer, A model for collaborative services in distributedlearning environments, Proc. IDMS’97, Lecture Notes in ComputerScience, 1309, Springer, Berlin, 1997, pp. 364–375.

[14] V. Hilt, Educational Multimedia Library Project, University ofMannheim, Lehrstuhl Praktische Informatik IV, URL: http://www.informatik.uni-mannheim.de/informatik/pi4/projects/emulib/index.en.html, 1998.

[15] E. Hinsch, A. Jaegemann, L. Wang, The secure conferencing useragent—a tool to provide secure conferencing with MBONE multi-media conferencing applications, Proc. IDMS’96, Lecture Notes inComputer Science, 1045, Springer, Berlin, 1996, pp. 131–142.

[16] W. Holfelder, Interactive remote recording and playback of multicastvideoconferences, Proc. IDMS’97, Lecture Notes in ComputerScience, 1309, Springer, Berlin, 1997, pp. 450–463.

[17] T. Kelemen, Evaluation and Integration of Efficient Signature andKey Exchange Algorithms on Elliptic Curves, Master’s Thesis (inGerman), University of Mannheim, 1998.

[18] M. Kerres, Multimediale und telemediale Lernumgebungen—Konzeption und Entwicklung, Oldenburg Verlag, Mu¨nchen, Wien,1998.


[19] J. Kilian, P. Rogaway, How to protect DES against exhaustive keysearch, Proc. Advances in Cryptology, Crypto’96Berlin, Springer,1996.

[20] W. Koch, GPG—The free PGP Replacement, URL: http://www.d.shuttle.de/isil/gnupg.html, 1998.

[21] K. Lai, On the Design and Security of Block Ciphers, ETH Series inInformation Processing, 1, Hartmut-Gorre-Verlag, Konstanz, 1992.

[22] K. Lai, Markov ciphers and differential cryptoanalysis, Proc. ofEUROCRYPT’91, Advances in Cryptology, Springer, Berlin, 1991.

[23] L. Lamport, Password authentication with insecure communication,Commun. ACM 24 (11) (1981).

[24] M. Luby, C. Rackoff, How to construct pseudo random permutationsfrom pseudo random functions, SIAM J. Comput. 17 (1988) 2.

[25] S. Lucks, Faster Luby-Rackoff ciphers, in: D. Gollmann (Ed.), Proc.Fast Software Encryption, Lecture Notes in Computer Science, 1039,Springer, Berlin, 1996.

[26] S. Lucks, BEAST: a fast block cipher for arbitrary blocksize, in: P.Hoprster (Ed.), Proc. IFIP’96, Conference on Communication andMultimedia Security, Chapman & Hall, London, 1996, pp. 144–153.

[27] S. Lucks, On the security of remotely keyed encryption, in: E. Biham(Ed.), Fast Software Encryption, Lecture Notes in Computer Science-Springer, Berlin, 1997.

[28] S. Lucks, Attacking triple encryption, in: S. Vaudenay (Ed.), Proc.Fast Software Encryption 5, Lecture Notes in Computer Science,1372, Springer, Berlin, 1998.

[29] S. Lucks, On the power of whitening. Manuscript, University ofMannheim, Fakulta¨t fur Mathematik und Informatik, 1998.

[30] S. Lucks, Accelerated Remotely Keyed Encryption, accepted: FastSoftware Encryption 1999, Rome, 1999.

[31] S. Lucks, R. Weis, V. Hilt, Fast encryption for set-top technologies,Proc. Multimedia Computing and Networking ‘99 (SPIE), San Jose,CA, January 1999.

[32] S. Lucks, R. Weis, Remotely keyed encryption using non-encryptingsmartcards, Proc. USENIX Workshop on Smartcard Technology,Chicago, 10–11 May 1999.

[33] M.R. Macedonia, D.P. Brutzmann, MBone provides audio and videoacross the Internet, IEEE Comput. 27 (4) (1994).

[34] K. Maly, C. Wild, C. Overstreet, H. Abdel-Wahab, A. Gupta, A.Youssef, E. Stoica, R. Talla, A. Prabhu, Virtual classrooms and inter-active remote instruction, Int. J. Innovations in Education 34 (1)(1996) pp. 44–51.

[36] MERCI, Multimedia European Research Conferencing Integration,Telematics for Research Project 1007, URL: http://www.mice.cs.ucl.ac.uk/mice/merci/, 1996-1998.

[37] J.K. Ousterhout, Tcl and Tk Toolkit, Addison-Wesley, Reading, MA,1994.

[38] P. Parnes, MOD: the multicast Media-on-Demand system, submittedto: NOSSDAV’97, URL: http://ctrl.cdt.luth.se/peppar/progs/mMOD/,1997.

[39] R. Rivest, A. Shamir, Payword and Micromint, URL: http://theory.lcs.mit.edu, rivest/RivestShamirmpay.ps

[40] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Trans-port Protocol for Real-Time Applications, Internet RFC 1889,IETF,1996.

[41] B. Schneier, Description of a new variable-length key, 64-bit blockcipher, Proc. Cambridge Security Workshop on Fast SoftwareEncryption, Lecture Notes in Computer Science, 809, Springer,Berlin, 1994, pp. 191–204.

[42] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, N. Ferguson,Twofish: a 128-bit block cipher, AES Submission, June (1998).

[43] TeleDraw, Part of the Telematics for Research Project 1007 MERCI,URL: http://www.uni-stuttgart.de/Rus/Projects/MERCI/MERCI/TeleDraw/Info.html, 1996–1998.

[44] R. Weis, Combined cryptoanalytic attacks against signature andencryption schemes (in German), in A la Card aktuell 23/97, 1997,p. 279.

[45] R. Weis, Moderne Blockchiffrierer (in German) in: Kryptographie,Weka-Fachzeitschriften-Verlag, Poing, 1998.

[46] R. Weis, A protocol improvement for high-bandwidth encryptionusing non-encrypting smartcards, submitted to: Information SecurityManagement and Small System Security, Amsterdam, 1999.

[47] R. Weis, W. Geyer, Cryptographic concepts for on-line feedback,Proc. New Learning Technology, Bern, Switzerland, 1999.

[48] R. Weis, M. Kuhn, Tron, Hacking Chipcards, Workshop CCC’97,Hamburg 1997.

[49] R. Weis, S. Lucks, Faster software encryption, Technical Report,University of Mannheim, Fakulta¨t Mathematik und Informatik, 1998.

[50] R. Weis, S. Lucks, How to Encrypt with Rabin, Technical Report,University of Mannheim, Fakulta¨t fur Mathematik und Informatik,1998.

[51] R. Weis, S. Lucks, Improved Security through Redundant RandomOracles, Technical Report, University of Mannheim, Fakulta¨t furMathematik und Informatik, 1998.

[52] World-Wide Web Consortium, Synchronized Multimedia IntegrationLanguage (SMIL) 1.0 Specification, W3C Recommendation, URL:http://www.w3.org/TR/REC-smil/, June 1998.


the design and the security concept of a collaborative whiteboard

Documents