0018-9162/07/$25.00 © 2007 IEEE24 Computer P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

C O M P U T I N G P R A C T I C E S

Challenges in SecuringNetworked J2MEApplications

An increasing number of smart phones support Java 2,

Micro Edition. Mobile application developers must deal

with J2ME’s inherent security weaknesses as well as bugs

in implementations on real devices.The new Security and

Trust Services API for J2ME addresses some of these

challenges, although it too has shortcomings.

A smart phone combines a full-featured mobile phone with advanced data andmultimedia functionality including PDA capabilities, Internet and e-mailaccess, and MP3 and video playback. It typically includes a large color touchscreen, a keyboard, Bluetooth technology to communicate with other devices,and substantially more memory and processing power than a regular mobile

phone. Another key feature is the ability to install additional applications. The smart phone market is growing fast,1 spurring development of new mobile

software for everything from gaming to online banking to GPS navigation. Forexample, total global revenue in the mobile gaming market is expected to soar from$2.6 billion in 2005 to $11.2 billion by 2010, with online multiplayer games gen-erating 20.5 percent of market share.2

Many different development platforms exist for smart phones, categorized by phone manufacturers, mobile operating systems, and device capabilities. Themost widespread is Java 2, Micro Edition (http:// java.sun.com/j2me), available onnearly 80 percent of currently marketed smart phones.

Experience gained during a commercial development project demonstrates howJ2ME technologies, particularly security-related functionality, are implemented onreal devices and provides insights into the problems researchers encounter during thedevelopment process.

J2ME TECHNOLOGIESThe Java 2 platform has several editions, including Enterprise Edition (J2EE) for

the server side and Standard Edition (J2SE) for desktop systems. J2ME is a highlyoptimized Java runtime environment aimed at mobile phones, PDAs, and othersmall devices.

Configurations and profilesJ2ME configurations are intended for devices with similar characteristics in

terms of processors and memory. Profiles target devices that are similar in termsof screen type, input devices, and network connectivity; they complement the low-level functionality of configurations by adding support for user interaction andnetwork connectivity.

André N.Klingsheim,Vebjørn Moen,and Kjell J. HoleUniversity of Bergen

r2klin.qxp 23/1/07 12:08 PM Page 24

February 2007 25

A configuration specifies the supported Java virtualmachine features, the included Java programming lan-guage features, and the supported Java libraries andapplication programming interfaces (APIs). Two con-figurations are widely available on J2ME devices:Connected Limited Device Configuration 1.0, which hasbeen around for years, and CLDC 1.1, which is deployedin newly released devices (http://java.sun.com/products/cldc). The most notable difference between the two con-figurations is that CLDC 1.1 adds support for floating-point operations. Because CLDC 1.1 is a superset ofCLDC 1.0, Java applications built for CLDC 1.0 willrun without problems on CLDC 1.1.Thus, unless any of the additions inversion 1.1 is specifically needed,developers should build their appli-cations for CLDC 1.0 to be compat-ible with as many devices as possible.

Two profiles extend CLDC func-tionality: Mobile Information De-vice Profile 1.0 and 2.0 (http://java.sun.com/products/midp). The MIDPprofiles add APIs for user interac-tion, network connectivity, and per-sistent storage. HTTP connections provide networkconnectivity, while a record management system pro-vides persistent storage. MIDP 2.0, a superset of MIDP1.0, includes support for secure HTTP (HTTPS) con-nections and more powerful graphics APIs for gaming.

SpecificationsNew J2EE/J2SE/J2ME specifications emerge through

the Java Community Process (JCP) program. Developersfirst submit a Java Specification Request for acceptanceby an executive committee. Once the committee acceptsa JSR, an expert group assumes responsibility for spec-ification development. The specification draft must firstpass a community review, then a public review. Theexpert group presents a proposed final draft, and anapproval ballot decides if the specification is suitable for release.

An expert group typically consists of many partici-pants. For example, the MIDP 2.0 expert groupincluded, among others, Ericsson, Motorola, Nokia,Siemens, Sun Microsystems, Samsung, and Symbian.Expert groups enable large industrial parties to collab-orate in specifying new functionality for the Java plat-form. This minimizes competition among differentvendor specifications and increases the likelihood of aspecification’s wide adoption. All CLDC versions andMIDP versions resulted from JSRs, as did several otherJ2ME components such as the Security and TrustServices API (JSR-177), the Wireless Messaging API(JSR-120), and the Java APIs for Bluetooth WirelessTechnology (JSR-82). All specifications are freely avail-able at the JCP Web site (www.jcp.org).

CURRENT CHALLENGESJ2ME developers face several challenges. J2ME-

enabled smart phones generally have some softwarequality issues, and developers are likely to spend timesolving problems resulting from the varying quality ofJ2ME implementations. Specific phone models can havetheir own bugs, forcing developers to maintain severalparallel versions of their source code to support as manydevices as possible.

This situation is inconsistent with the Java philosophyof “write once, run anywhere,” and it severely increasesthe complexity of mobile software development and

maintenance. In our experience,MIDP 2.0 implementations havefewer bugs than MIDP 1.0 imple-mentations. However, to cover asmuch of the market as possible,developers must consider all existingMIDP 1.0 devices. MIDP 2.0 devicesstill constitute a minority of all J2MEdevices sold in recent years.

Insufficient testingMany developers fail to recognize

that J2ME devices can behave inconsistently. TestingJ2ME applications on many different devices is criticalto ensuring that security-related functionality meetsexpectations. Businesses that base their testing on onlyfour or five devices are often surprised when their appli-cation does not run correctly on other devices. In ouropinion, too many businesses neglect the testing phaseand let their customers do the beta testing. For such astrategy to succeed, the application must be unique andcustomers must be both enthusiastic and understanding.

To truly appreciate how J2ME phones operate, devel-opers should test several devices from each major ven-dor, with each version of a vendor’s developmentplatform represented in the set of test devices. Of course,testing 40 to 50 or more devices is expensive. Businessesthus must carefully balance the cost of testing with therisk of releasing an application that might not functionproperly on some devices.

Permanent bugsDesktop users commonly download patches from

Microsoft Windows Update or similar Web sites tosolve security issues and fix bugs in software. Mobilephone vendors also release new software versions, butthese generally do not reach consumers who havealready bought the device. In most cases, users musttake their mobile phone to a repair shop to have a soft-ware upgrade performed. Since few people actually dothis, the bugs on a new mobile phone usually stay therefor the device’s lifetime. However, a user who buys thesame phone a year later will probably get a newer soft-ware version.

Many developers

fail to

recognize that

J2ME devices

can behave

inconsistently.

r2klin.qxp 23/1/07 12:08 PM Page 25

26 Computer

With mobile phone viruses starting to appear, there isa growing need for a patching solution that lets con-sumers upgrade the phone software themselves, similarto what they hopefully do with their desktop systems.

Resource managementAlthough smart phones have more memory, process-

ing power, network bandwidth, and disk space thanstandard mobile phones, they are still a resource-con-strained platform compared to the desktop. In additionto traditional functionality, developers must thus con-sider effective resource utilization to make user-friendlymobile applications.

Defensive programming is the keyto creating a well-functioning appli-cation. For example, a program canquery available runtime memoryand storage memory while execut-ing to ensure that the device hasenough memory to carry out theprogram’s operations. Otherwise, ifthe device runs out of memory, itwill show an error message and ter-minate the application, giving theuser the impression that an error occurred when in factthe application did not adapt to the available resources.

Scarce resources limit developers’ options, as func-tionality-rich security libraries can be too complex tobundle with an application. After all, if a J2ME imple-mentation had the capacity to store and run such alibrary, it could have included one in the first place.The use of these libraries is not impossible, but olderdevices might not have the capacity to install and runthe application.

Responsive applicationsApplications must be responsive to provide a positive

user experience. To achieve this goal, intimate knowl-edge of J2ME devices’ inner workings is helpful, sincemobile phones behave differently. One example isactively triggering garbage collection to reclaim mem-ory from unused objects. In most cases, running agarbage collector in the background will minimallyimpact the application, but some devices will freeze fora few seconds while collecting memory, which is prob-ably not what the developer wants or expects.

Multithreading is also important when developingapplications for mobile phones. A program’s executionflow is event-driven, so the main thread must be idle andready to handle events. Time-consuming operations suchas lengthy calculations or network communicationshould thus occur in a separate thread to retain a respon-sive user interface. This should be familiar to thosedeveloping graphical user interface applications on thedesktop, as the same UI versus non-UI thread consider-ations apply.

MIDP 2.0 SECURITY FRAMEWORKMIDP 2.0 includes several mechanisms to secure appli-

cations and communication channels. Applications canbe signed to obtain authenticity and integrity, whileHTTPS connections realize secure communication chan-nels, which in most cases rely on the Secure Sockets Layer(SSL) or Transport Layer Security (TLS) protocol. In addi-tion, MIDP 2.0 tries to ensure that an application cannotread other J2ME applications’ persistent data withoutexplicit permission.

However, studying MIDP 2.0’s details reveals thatsome critical security functionality is actually optional

on J2ME devices or can be based oninsecure mechanisms. Developerswill also be disappointed to realizethat, when real testing begins, somesmart phones do not correctlyimplement mandatory security func-tionality.

Application signingX.509 public-key infrastructure

(PKI)-based signature verification,3

an optional feature in the MIDP 2.0specification, lets devices verify a signed J2ME applica-tion’s origin and integrity. Signed applications are gen-erally desirable for m-commerce and mobile governmentservices, but when users install a signed application ondevices that do not verify signatures, parts of the secu-rity architecture crumble.

In fact, two newly released Samsung smart phones wetested during our project refused to install J2ME appli-cations signed with the private key belonging to a code-signing certificate obtained from Verisign. However, theNokia devices we tested validated the certificate andapplications without problems.

To support all devices, developers must provide bothsigned and unsigned versions of applications to cus-tomers, effectively making the security architecture’ssigned application feature optional.

Certificate management and verificationAll certificate verification procedures on a mobile

phone rely on a set of preinstalled root certificates(belonging to certificate authorities), equivalent to whatis present in Web browsers. Of course, different mobilephones have different root certificates installed.

Additional root certificates can be installed on smartphones, which is very useful during a test phase. We suc-cessfully created and installed a self-signed X.509v3 cer-tificate on the Nokia 6600 by publishing it to a Webserver and then downloading it to the phone via theWireless Application Protocol (WAP). A certain level ofuser interaction was needed after installing the certifi-cate, as all certificates in this device have propertiesdescribing their area of use. A user-installed certificate

Functionality-rich

security libraries

can be

too complex

to bundle with

an application.

r2klin.qxp 23/1/07 12:08 PM Page 26

February 2007 27

must thus be enabled for verification of signed applica-tions or server authentication before it can be used.

An important requirement when working with certificates is the ability to validate a certificate. Time-limited validity is one mechanism, but support for cer-tificate revocation is more critical. “Certificaterevocation can be performed if the appropriate mecha-nism is implemented on the device,” MIDP 2.0 states.“Such mechanisms are not part of MIDP implementa-tion and thus do not form a part of the MIDP 2.0 secu-rity framework.” Consequently, a certificate’s validitymust be based on the assumption that it has not beenrevoked.

During our project, we observedthat the Samsung SGH-E720 hadpreinstalled Verisign class 1, 2, 3,and 4 root certificates reported validfrom 1 October 1999 to 1 January1970. (Other preinstalled certificatesshowed sensible validity intervals.)The same Verisign root certificateson the Nokia 6600 all had a 1October 2049 expiration date.Giving Samsung the benefit of thedoubt, we assume that the invalid date is not the valueactually stored in the certificate. However, because thedate is not presented correctly, the expiration date mightnot be interpreted correctly during the certificate vali-dation process. Unfortunately, we could not verify this,as finding a Web site that uses a certificate signed by aspecific root certificate is not a trivial task.

Secure communicationSecure connections in MIDP 2.0 must be implemented

by one or more of the following specifications:

• HTTP over TLS (RFC 2818) with TLS v1.0 (RFC2246),

• SSL v3.0, • Wireless Transport Layer Security (WTLS), or • WAP TLS Profile and Tunneling Specification.

A developer cannot know which specifications areimplemented on a specific device without actually test-ing it. In the case of WTLS, end-to-end encryption is notprovided. Secure connections will then exist between thephone and the WAP gateway and from the gateway tothe final destination. Thus, the gateway has access tounencrypted data and must be fully trusted. This is unac-ceptable for a high-security application, as the mobilenetwork provider usually operates the gateway.

In addition, secure connections in MIDP 2.0 requirethe server to have a valid certificate for authentication.However, there is no support for certificate-basedauthentication of the client, so the client must be authen-ticated at the application level by other means.

Secure storageMIDP 2.0 does not support encrypted storage, making

it vulnerable to hardware attacks. On some devices it ispossible to install a file system explorer, locate the filesthat J2ME uses, and send those files to another devicevia Bluetooth technology. Thus, J2ME’s storage systemcannot be trusted with sensitive data unless the applica-tion itself secures the data. Cryptographic libraries forJava might be a partial solution—for example, BouncyCastle’s lightweight cryptography API supports severalsymmetric ciphers. However, the availability of crypto-graphic APIs does not automatically solve the plaintext

storage problem.Encryption is a computation-

intensive task, and when imple-mented in Java it can be time-consuming because low-level opti-mizations such as those for CPUarchitecture are impossible. Nativelibraries or cryptographic hardwareare likely to perform encryptionmore efficiently.

Another important issue is the lackof sources of randomness in J2ME

implementations. A strong cipher can be used, but theencryption key must be impossible to guess. MIDP 2.0does not provide a cryptographically strong pseudoran-dom number generator similar to SecureRandom inJ2SE. Thus, the PRNG in J2ME is not suitable for gen-erating encryption keys. Nevertheless, developers use itfor other purposes, and this can have a major impact ona system’s security, especially since they tend to seed thePRNG with the current time.4 One example is an attackon SSL in Sun’s MIDP reference implementation.5

Because MIDP 2.0 does not provide encrypted stor-age and MIDP 1.0 does not provide HTTPS links, someJ2ME development companies specify their own light-weight cryptographic schemes. In most cases, these well-meaning efforts to create new cryptographic algorithmsresult in solutions that keep data hidden from averageusers but are rarely cryptographically strong. Such ini-tiatives usually rely on the secrecy of the encryption algo-rithm, which is considered very bad practice.4

Many countries have laws regulating the protectionof private data during transportation over a mediumthat the two communicating parties do not control.These laws often require encrypting the data with analgorithm of strength equal to or better than the TripleData Encryption Standard; its successor, the AdvancedEncryption Standard, also fulfills this requirement.However, homemade cryptographic solutions almostcertainly lack the strength of well-tested encryption algo-rithms such as 3DES or AES.

USING CLIENTS TO ATTACK THE SERVERBeyond the well-known problem of Internet server

The lack of sources

of randomness

in J2ME

implementations

is an important

issue.

r2klin.qxp 23/1/07 12:08 PM Page 27

28 Computer

attacks from viruses and worms and distributed denial-of-service attacks, developers must consider the manyways in which client applications can attack the serverapplication. Two examples are clients sending commandsout of order or sending unexpectedly large data chunksas input to an application.

Client software can find its way into the hands of allkinds of people, including those who cannot resist try-ing to break it. Hackers can reverse engineer softwareand study the source code or, short of that, simply tam-per with the binary code. The gaming industry is expe-riencing the problem of games being cracked to avoidlicense key checks on a daily basis.Another strategy hackers employ isto use a network sniffer to identifythe application protocol and thenwrite their own malicious client thatbehaves similarly to the original one.

Developers can take several mea-sures to increase the level of securityin a client-server application, but inour experience, most place too muchtrust in their client software. Theirarguments are along the lines of:“Hey, we wrote it. Why shouldn’t we trust it?” In ouropinion, this is a dangerous attitude.

FUTURE J2ME SECURITY: SATSAThe new Security and Trust Services API (http://

java.sun.com/products/satsa) for J2ME addresses sev-eral shortcomings in the MIDP 2.0 security architecture.SATSA relies on a security element implemented in eithersoftware or hardware. This implies that the SE can takedifferent forms such as a software component, dedicatedhardware in the device, or a removable smart card.Several SEs can be available in one device. The exactform of the SE is transparent to the application devel-oper, as the SATSA implementation handles interactionwith the SE.

Support for cryptographic smart cards is particularlyuseful to developers writing J2ME applications for smartphones. A smart card can store keys and certificates andsign data without the private key ever leaving the card.High-end smart cards are tamper-resistant and provideauthentication schemes, such as requiring a PIN or apassword before granting access. Private keys need notbe stored on diverse insecure clients, enabling vendors tofocus on protecting the smart card from physical intru-sion and, just as important, API exploitation.6

Many banks already issue smart cards that include amagnetic strip to be compatible with old ATMs. By giv-ing customers smart cards with cryptographic tools, abank could also provide client software for mobilephones, PDAs, and desktop computers, thereby extend-ing nearly the same level of security for key storage onall platforms. Of course, different operating systems

have different levels of security, so the bank would haveto carefully analyze each platform to control smartcard access.

SATSA APIsThe SATSA specification defines four APIs: APDU,

JCRMI, PKI, and CRYPTO. The first two add func-tionality for smart card interaction. SATSA-APDUenables communication with smart cards using theApplication Protocol Data Unit protocol that theISO7816-4 specification defines, while SATSA-JCRMIenables high-level communication with smart cards

through the Java Card RemoteMethod Invocation Protocol.

SATSA-PKI lets applications re-quest digital signatures from an SE,thereby providing authentication andpossibly nonrepudiation3 using keysstored on a smart card. Certificatemanagement gives applications theopportunity to add or remove clientcertificates from an SE. It alsoincludes the possibility to requestgeneration of a new key-pair and

then produce a Certificate Signing Request. Having theclient generate its own keys is a critical element in sup-porting nonrepudiation in a system. Because the SE mightnot support key generation, the developer must chooseit with care, considering the application requirements.

SATSA-CRYPTO offers cryptographic tools includ-ing message digests, digital signature verification, andciphers that let applications store data encrypted andsigned on a mobile device, ensuring both confidential-ity and integrity for sensitive information. It is up to theSATSA implementer to decide which ciphers and digestalgorithms to include. The specification recommendsDES, 3DES, and AES as symmetric ciphers, RSA as anasymmetric cipher, and the Secure Hash Algorithm ver-sion 1 as the digest algorithm. SHA1 with RSA is therecommended algorithm for digital signatures.

Operating system issuesSATSA is distributed as a part of the Java Runtime

Environment in some smart phones. The phone’s oper-ating system must thus be fully trusted, as the JREdepends on services from the OS. The SATSA specifica-tion states that both SATSA and the application usingit must trust the OS. When SATSA assumes UI control—for example, when asking the user for the smart cardPIN—the UI must be distinguishable from one gener-ated by external sources to prevent a malicious appli-cation from mimicking the SATSA UI. Further, externalsources cannot be able to retrieve or insert the PIN.These requirements put a lot of responsibility on the OS.

Because a user enters the PIN on the device throughthe keypad, a keylogger application could possibly

Support for cryptographic

smart cards is

particularly useful

to developers writing

J2ME applications

for smart phones.

r2klin.qxp 23/1/07 12:08 PM Page 28

February 2007 29

obtain the number. Thus, the OS must limit the distri-bution of key-pressed events to the SATSA implemen-tation exclusively. Keyloggers exist for Symbian OSversions prior to version 9, so this could be a real issue.Another potential problem is that the OS stores the PINin memory before handing it over to the smart card;other applications could possibly read this memory.

J2ME applications use a per-application dedicatedlogical channel to communicate with the smart card.This channel might be vulnerable to hijacking via theOS’s low-level functionality. A hacker who acquiresaccess to the smart card on a level below the SATSAimplementation could send requeststo the smart card, circumventing theimplementation. If this functionalitywas included in, for example, aTrojan horse, the attacker couldhave full access to the smart cardwithout the user’s knowledge.

These scenarios illustrate prob-lems with putting complete trust inthe OS. In our opinion, an applica-tion cannot be more secure than theOS it runs on. It remains to be seen how the mobileplatform copes with viral threats, as mobile phoneviruses are only beginning to emerge.

The Trusted Computing Group has proposed an ini-tiative to make OSs on mobile devices more secure(www.trustedcomputinggroup.org/groups/mobile). In thefuture, mobile devices are likely to become more trust-worthy, facilitating development of secure applications.

SATSA shortcomingsClient certificates that the SATSA implementation

stores cannot be used for authentication while settingup HTTPS links using SSL or TLS. Developers thusmust handle certificate-based client authenticationthemselves.

One alternative is to open an SSL connection to aserver, which authenticates the server and provides asecure communication channel. Client authenticationcan then be carried out using a certificate provided bythe client application and having the client sign a chal-lenge from the server.

This scheme withstands dictionary or brute-forceattacks and is thus more robust than widely used pass-word authentication. Consequently, SATSA can improvesecurity in current client-server applications by replac-ing old-fashioned authentication schemes. However, itwould be convenient if SSL or TLS implementationsfound in most newer smart phones could use the clientcertificates the SATSA implementation stores.

Signature verification with SATSA is more difficultthan signature creation. SATSA generates signed mes-sages on the Cryptographic Message Syntax format butdoes not easily validate them. To verify a signature, the

application must first split a message into its respectivedata and signature parts and then supply a public key.Libraries exist for handling CMS messages, so develop-ers need not implement CMS message parsing. However,it would be easier if SATSA could verify its own signed messages.

In addition, SATSA handles signature generation andverification differently. The underlying SATSA imple-mentation takes control of the UI and presents the userwith the certificate for signing along with the data tosign. The user can then be confident in signing theintended data. Signature verification is just as impor-

tant, but in this case the applicationmust present details about the signa-ture to the user. In other words, youtrust SATSA when signing data andthe application to show you correctinformation when verifying signa-tures. Ideally, SATSA should betrusted on both occasions.

Moreover, SATSA does not sup-port certificate verification. Thedeveloper must implement the cer-

tificate verification process and public-key extractionfrom the certificate, along with presenting the certificateand signed data to the user. SATSA provides the mostbasic building blocks for PKI-enabled applications, butit does not include any certificate validation functional-ity present in J2SE.

Finally, private keys stored on the smart card cannotbe used for decryption, as they are accessible only forsigning. SATSA supports asymmetric cryptography, andthe ability to select a certificate and its correspondingprivate key for decryption would be convenient. Datacould then be decrypted on the smart card, withoutexposing the private key to the application or OS.

D eveloping secure J2ME applications is difficult dueto limitations in the J2ME security model as wellas bugs in real devices. A proper security analysis

and testing of real devices must be carried out to deter-mine the level of security that can be achieved.

The SATSA specification adds cryptographic capabil-ities to the J2ME platform. With SATSA, symmetricencryption is possible, and authentication schemes canrely on public-key cryptography instead of the usualusername and password authentication. User certificatestorage and support for digital signatures in smart cardsopen up possibilities for applications that require a highlevel of security.

Although SATSA is a good fit for scenarios requiringstrong client authentication and digital signatures onbehalf of the client, it provides only the basic crypto-graphic building blocks for a PKI. Important function-ality found in J2SE such as certificate parsing,

An application

cannot be

more secure

than the OS

it runs on.

r2klin.qxp 23/1/07 12:08 PM Page 29

30 Computer

validation, and storage is left to the developer.Implementing signature validation and public-key cryp-tography based on public keys in certificates thusremain complex tasks. ■

Acknowledgment

We thank World Medical Center Norway for itscooperation during this project and for giving us accessto the mobile phones needed to conduct the security-related tests.

References

1. Canalys.com, “Worldwide Smart Phone Market Soars in Q3,”25 Oct. 2005; www.canalys.com/pr/2006/r2006071.htm.

2. Telecoms.com, “Mobile Games Industry Worth USD $11.2Billion by 2010,” 19 May 2005; www.telecoms.com/itmgcontent/tcoms/search/articles/20017303052.html.

3. C. Adams and S. Lloyd, Understanding PKI: Concepts, Stan-dards, and Deployment Considerations, Addison-Wesley Pro-fessional, 2nd ed., 2002.

4. J. Viega and G. McGraw, Building Secure Software: How toAvoid Security Problems the Right Way, Addison-Wesley Pro-fessional, 2001.

5. K.I.F. Simonsen, V. Moen, and K.J. Hole, “Attack on Sun’sMIDP Reference Implementation of SSL,” Proc. 10th NordicWorkshop Secure IT-Systems, 2005, pp. 96-103; www.nowires.org/Papers-PDF/MIDP-SSL.pdf.

6. R. Anderson et al., “Cryptographic Processors—A Survey,”Proc. IEEE, vol. 94, no. 2, 2006, pp. 357-369.

André N. Klingsheim is a PhD student in the Departmentof Informatics, University of Bergen, Norway. His researchinterests include network and application security. Kling-sheim received an MSc in computer science from the Uni-versity of Bergen. He is a member of the IEEE ComputerSociety. Contact him at klings@ii.uib.no.

Vebjørn Moen is a researcher in the Department of Infor-matics, University of Bergen. His research interests includenetwork and application security. Moen received a PhD incomputer science from the University of Bergen. Contacthim at moen@ii.uib.no.

Kjell J. Hole is a professor in the Department of Informat-ics, University of Bergen. His research interests include net-work and application security. Hole received a PhD incomputer science from the University of Bergen. He is amember of the IEEE Computer Society. Contact him atkjell.hole@ii.uib.no.

■ Monthly updates highlight the latest additions to the digital library from all 23 peer-reviewed Computer Society periodicals.

■ New links access recent Computer Society conference publications.

■ Sponsors offer readers special deals on products and events.

Available for FREE to members, students, and computing professionals.

Visit http://www.computer.org/services/csdl_subscribe

For the IEEE Computer Society Digital Library E-Mail Newsletter

Sign

Up

Toda

y

r2klin.qxp 23/1/07 12:08 PM Page 30