March ❘ April 2002 IT Pro 531520-9202/02/$17.00 © 2002 IEEE

Secure Peer-to-PeerNetworking:The JXTA ExampleWilliam Yeager and Joseph Williams

T he rise of Napster andits technical descen-dants—Gnutella, Mor-pheus,and others—has

probably caught everyone’sattention by now. These prod-ucts rely on an abbreviatedform of distributed computingto connect millions of users, let-ting them share music, videos,images,and other files.The tech-nology that enables this form of

distributed computing is calledpeer-to-peer computing or peer-to-peer networking, dependingon your view of the technology;most people simply refer to it asP2P.

File sharing is just one aspectof P2P, as the “What is P2P?”sidebar discusses. Companiesare developing applications thatwill use P2P networking to cre-ate ad hoc work groups and vir-tual communities.When marriedwith mobile technologies, suchas the Wireless ApplicationProtocol or IEEE 802.11, P2Pcan also become the foundationfor offering location-based ser-vices. Such services can supportvirtual play groups, such as stu-

dents communicating with eachother at a ski resort. Or they cansupport emergency services,such as an ad hoc computingenvironment for a hazardous-materials clean-up team.Projects like the Search forExtraterrestrial Intelligence(SETI) At-Home also let P2Pnetworks share computingcycles among computers.

P2P has so captured the busi-ness community’s imaginationthat Fortune magazine recentlyfeatured P2P as one of the fourtechnologies that will shape theInternet’s future (Erick Schon-feld, “Post-Napster, Peer-to-Peer Computing Gets Readyfor Prime Time,” Fortune, 25Oct. 2001).

An open-source framework,JXTA can accommodate centralized and decentralized certificateauthorities for P2P networking.

BASIC PREMISE OF P2PA P2P application has to deal

with several computers (peers)running on different physicalmachines. These peers can berunning a daunting variety orversions of operating systems,and work in varied security,application, and tools environ-ments. Given a collection ofsuch peers, how do you createP2P applications? For starters,you need a way for peers tocommunicate and a way touniquely identify each peer inthe network. Since most P2Pnetworks are ad hoc, the net-work must dynamically dis-cover peers and track whenpeers join or leave the group.

Once you start connecting

There actually isn’t a universally accepted definition of peer-to-peer computing or networking; people have applied theterm to a wide range of technologies. In general, P2P describesan environment where computers (hosts) connect to eachother in a distributed environment that does not use a cen-tralized control point to route or connect data traffic. In prac-tice, P2P technologies deployed today adopt a network-basedcomputing style that neither excludes nor inherently dependson centralized control points.

Napster wasn’t really a pure example of P2P technology,because it relied on centralized servers to connect its user com-munity. A simple example of a P2P implementation comesfrom the IEEE 802.11b’s ad hoc working-group mode. In thismode, computers join a wireless network as peers, and everycomputer in the network can communicate directly with everyother computer in the network without having to first com-municate with a centralized server.

What is P2P?

54 IT Pro March ❘ April 2002

E V O L V I N G T E C H N O L O G I E S

these peers, security becomes an issue.Sharing files and other computingresources among peers opens up anenormous potential for hackers, van-dals, and thieves to disrupt and sub-vert the peered computers. In fact,opponents of P2P often cite authen-tication, authorization, and privacyconcerns as the primary roadblocks tothe general deployment of P2P net-works. Sharing music files in a P2Penvironment is one thing, but sharingsensitive corporate information isquite another.

JXTA (pronounced “juxta”)addresses these security concerns; itis a popular, open-source frameworkfor enabling P2P networking.

JXTAIn April 2001, Sun CEO Bill Joy

unveiled Project JXTA, a communitydevelopment project to create a newprogramming platform. He wantedthis project to solve several problemsin modern distributed computing,especially in P2P computing.

Project JXTA has the followingobjectives, intending to address theshortcomings of current or develop-ing peer-to-peer systems:

• Interoperability. Interconnectedpeers must easily locate and com-

municate with each other; partici-pate in community-based activities;and offer services to each otherseamlessly across different P2P sys-tems and communities.

• Platform independence. P2P mustbe independent of programminglanguages, such as C or Java; systemplatforms, such as the MicrosoftWindows and Unix operating sys-tems; and networking platforms,such as TCP/IP (transmission con-trol protocol/Internet protocol) orBluetooth.

• Ubiquity.P2P has its broadest reachwhen it works with any device hav-ing a digital heartbeat, includingsensors, consumer electronics,PDAs (personal digital assistants),appliances, network routers, desk-top computers, data center servers,and storage systems.

JXTA relies heavily on XML (Ex-tensible Markup Language). It alsoseparates its protocols from specificlanguage bindings, which in effectmakes it language independent (PirozMohseni, “An Overview of JXTAArchitecture,” http://softwaredev.earthweb.com/java/article/0,,12082_783281,00.html).The JXTA specifica-tion does not indicate when or whyvarious computing devices can form a

For more information aboutProject JXTA, visit its Web site at http://www.jxta.org.The site hostsdocumen-tation, JXTAsource code,sample applica-tions, and techni-cal discussions.

The security project team forProject JXTA has developed a Web-of-trust-based security model forJXTA. This model uses public-keycryptography to let groups of peers

communicate securely(http://security.jxta.org

for more information).Project JXTA initially

began with a small group ofengineers at Sun Micro-systems along with the par-

ticipation of a small butgrowing number of experts

from academia and industry.Sun now distributes JXTA underan open-source license.As an open-source product, JXTA has a com-munity of P2P-interested usershelping to codevelop it.

Learn More about JXTApeer group; it simply supplies theinfrastructure for forming and man-aging groups. Once JXTA enables anetwork of peers, communicationamong peers occurs via a pipe (chan-nel). Messages sent into a pipe go toall peer hosts that are listening to thatpipe. The Pipe Binding protocol con-trols how peers connect and discon-nect to a pipe at runtime. In contrastto these multipeer pipes, a point-to-point pipe permits one-way commu-nication between two peers (thusreducing network traffic).

Pipes, peers, and services communi-cate with each other via advertise-ments and by using XML. Typicalpeer advertisements describe infor-mation such as name, peer id, proper-ties, and services offered. JXTA hasseveral core advertisement types—peer, peer group, pipe, service, con-tent, endpoint, and user defined.

In short, JXTA allows for manage-ment of peers individually and as agroup. It allows for communicationamong peers via pipes and also definesthe message structure exchangedamong peers in advertisements.

There are several other P2P tech-nologies, of course. Many of thesehave been popularized by the music-sharing phenomena. Groove (http://www.groove.com), Morpheus (http://www.musiccity.com), and Napster(http://www.napster.com) all, to someextent, deploy self-organizing, file-sharing systems. Microsoft also has a P2P technology in the WindowsMessenger core that enables itsPresence and Instant Messaging plat-forms. Each of these is a proprietarytechnology, so this presentation of theopen-source JXTA platform providesa generalized vehicle for discussingthe P2P security problem.

SECURITYBefore developers can build new

enterprise and mission-critical appli-cations, JXTA must address security.Some security questions are quitefundamental: How will a peer-to-peerenvironment deal with security? Cansuch networks use the same notions

March ❘ April 2002 IT Pro 55

• use of X509 version 3 digital cer-tificates in a way that neither man-dates nor excludes centralizedcertificate authorities.

Because this approach doesn’trequire inventing new technologies,plans for applications developmentand deployment can proceed withminimal delay.Employing establishedtechnologies and protocols also trans-lates into a higher level of trust fromthe outset. It also obviates the need toradically shift the industry’s thinkingabout how to provide security.

Transport Layer SecurityJXTA has adopted TLS version 1 to

support reliable, private connectionsbetween peers. Figure 1 shows anupper layer, the JXTA virtual TLStransport. The lower layer is theJXTA virtual network.Thus, we havethe TLS transport multiplexing mul-

tiple pipe connections between twopeers on the JXTA virtual network.The TLS specification is currentlyunder development by the InternetEngineering Task Force (IETF) net-work working group. Although TLSand Secure Sockets Layer—a morewell-known network security proto-col—share several similarities, theyweren’t designed to be strictly com-patible, although most developersdon’t expect a hardship in supportingboth protocols.

The rationale for selecting TLS foruse by Project JXTA is identical tothat cited by the IETF: cryptographicsecurity—the protocol should be ableto establish a trusted connectionbetween two parties.

The protocol’s interoperability isalso important. Independent pro-grammers should be able to developapplications that can successfullyexchange cryptographic parameters

Peer ID 3

Peer ID 2

Relay

Peer ID 4

Peer ID 4

Peer ID 5

Peer ID 5

Peer ID 6

JXTAmessages

Application data

I/O pipes

JXTAmessages

Application data

I/O pipes

Peer ID 6

Firewall

Firewall

Peer ID 1

Peer ID 3

Peer ID 2

Peer ID 1 Relay

Relay

Virtual TLS transport

Figure 1. JXTA uses Transport Layer Security.

of trust, authentication, integrity, andnonrepudiation that IT professionalsexpect from traditional networks?Must users and application develop-ers radically alter their ideas abouthow to provide security when work-ing with P2P technologies?

The JXTA community is consider-ing a security model that relies onexisting trusted technologies, withoutcompromising the strong security thatusers and enterprises expect from tra-ditional computing approaches. Suchan approach is practical as a conse-quence of three recent choices by theProject JXTA team:

• the adoption of Transport LayerSecurity, an emerging industry pro-tocol for the secure transport ofinformation;

• exploitation of the JXTA proto-cols’ end-to-end transport inde-pendence; and

56 IT Pro March ❘ April 2002

without knowledge of one another’scode.

Because new public-key and bulkencryption methods will arise overtime, the protocol should also beadaptable enough to incorporatethem. This extensibility will also pre-vent the need to create a new protocol(and the attendant weaknesses ofdoing so), avoiding the need toimplement new security libraries.

Any cryptographic protocol shouldalso be relatively efficient. Crypto-graphic operations, particularly thosefor public key, tend to be highly CPUintensive. For this reason, the proto-col should incorporate schemes toreduce the number of connectionsand improve network efficiency.

TLS has two layers: the TLS recordand the TLS handshake protocols.

Record protocol. At the lowestlevel, layered on top of a reliabletransport protocol like TCP, is theTLS record protocol. It provides con-nection security in two ways:

• TLS connections are private. Theseconnections use symmetric cryp-tography—triple DES (DigitalEncryption Standard), RC4, andother algorithms—for data encryp-tion.TLS generates unique keys foreach connection and bases them ona secret negotiated by another pro-tocol (such as the TLS handshakeprotocol).Applications can also usethe record protocol without encryp-tion.

• TLS connections are reliable.Message transport includes a mes-sage integrity check that uses a hashmessage authentication code(HMAC) or keyed messageauthentication code. TLS usessecure hash functions—such asSHA-1 (Secure Hash Algorithm),MD5 (Message Digest 5), and oth-ers—for MAC computations.

The connection uses the TLS recordprotocol to encapsulate varioushigher-level protocols.

Handshake protocol. One suchencapsulated protocol, the TLS hand-shake protocol, lets the server andclient authenticate each other andnegotiate an encryption algorithmand cryptographic keys before theapplication protocol transmits orreceives its first byte of data.The TLShandshake protocol provides connec-tion security that has three basic prop-erties:

• The protocol can authenticate thepeer’s identity using asymmetric(public-key) cryptography algo-rithms, such as RSA (Rivest-Shamir-Adleman) and the DigitalSignature Standard.An applicationcan make this authenticationoptional, but minimal security usu-ally requires authentication of atleast one peer.

• The negotiation of a shared secretis secure. Eavesdroppers cannotpick up this secret, and for any

authenticated connection, thesecret is unobtainable, even by anattacker who places himself in themiddle of the connection.

• The negotiation is reliable. Noattacker can modify the negotiationcommunication without beingdetected by the communicatingparties.

An added advantage of TLS is itsindependence of application protocol.Implementations can layer high-levelprotocols on top of TLS transparently.The TLS standard, however, does notspecify how to do this layering. Forsources of TLS information see the“Advanced References for TLS”side-bar.

End-to-end transport independence of JXTA protocols

At one layer of abstraction, JXTAtechnology is a set of protocols witheach protocol defined by one or moremessages exchanged among peers.Each message has a predefined for-mat and can include multiple datafields. In this regard, JXTA is akin toTCP/IP—TCP/IP links Internetnodes together,and JXTA technologyconnects peer nodes. Because it ismerely a set of protocols, TCP/IP isplatform-independent; so is JXTA.Moreover, JXTA technology is trans-port independent and can use TCP/IPas well as other transport standardswith no impact on the messages them-selves.

Aside from providing an excep-tionally flexible architecture forimplementation on a wide variety ofdevices, this transport independencehas important consequences forJXTA security. Many users familiarwith the Wireless ApplicationProtocol (WAP) are probably alsoacquainted with the notion of the so-called “WAP gap.” This potentialsecurity breech exists when messagesmoving between wireless and wirednetworks must pass through a gate-way and undergo a protocol conver-sion. This process exposes the clear

E V O L V I N G T E C H N O L O G I E S

The Internet Engineer-ing Task Force offers de-tailed information onTLS at http://www.ietf.org/rfc/rfc2246.txt. In addi-tion, a reference from EricRescorla, SSL and TLS: De-signing and Building SecureSystems (Addison Wesley,2000) gives further explanations

of SSL and TLS.Because of its wide-

spread popularity andBerkeley-style licensing

policies, Pure TLS, animplementation from Clay-more Systems (http://www.

claymoresystems.com), is thebrand of TLS included in

JXTA distribution.

Advanced References for TLS

March ❘ April 2002 IT Pro 57

text of messages and can lead to asecurity compromise.

JXTA users will not have this expo-sure, because JXTA messages areindependent of the underlying trans-port and its protocols. Encrypted con-tent remains encrypted, even duringthe protocol conversions that occurbetween networks. This is a naturalconsequence of JXTA’s design andrequires no special actions by users orprogrammers.

P2P applications based on JXTAtechnology can use the strongestencryption algorithms available,with-out concern that anyone but autho-rized parties will see clear-textmessages related to the transaction.

Digital certificates and certificate authorities

Authentication and nonrepudiationare central concerns in electronicsecurity. Both ensure the identities ofparties to a transaction.A highly reli-able and widely used scheme forachieving these goals has incorpo-rated digital signatures and public-key cryptography.

Further, to ensure that no party toa transaction is an impersonator,secure systems can use digital certifi-cates, documents that bind a user to apublic key.At a minimum, certificatescontain a public key and a name.Theycan also contain an expiration date,the name of the certificate authority(CA) that issued the certificate, a ser-ial number, and the certificate issuer’sdigital signature. A CA’s key benefitis that some entity is willing to say thatit has unambiguously established theidentity of an individual who is usinga specific key. Parties correspondingwith this individual can then have asecure transaction with the CA to ver-ify the individual’s identity.

Digital certificates come from atrusted third party or an X509-ver-sion-3-compliant CA willing to vouchfor an identity and public-key pair.The CA can also be the individual’semployer or a third party specializingin sponsoring unaffiliated parties. CApolicies vary, depending on the

strength of authentication required byusers and the CA’s specific functionalrequirements.

Despite these benefits, the notion ofa centralized CA is not always appro-priate to the world of peer-to-peercomputing and is at times contradic-tory.

Large numbers of peers could wantto conduct a secure transaction with-out involving a centralized infrastruc-ture. Fortunately, the answer issimple—JXTA lets peers becometheir own CA, generating their ownroot certificates, verifying that theyare associated with a specific publickey. Larger groups have the addedflexibility of designating root CAs fora peer group.The group can then usethese root CAs as a strong way toauthenticate membership and estab-lish nonrepudiation within the peergroup.

In JXTA, peers can also form peergroups and designate one member asthe group’s CA, making its root cer-tificate part of the peer group’s binaryversion of JXTA. Or a group membercan transfer this root certificate to aprospective member over a TLS con-nection with out-of-band identity ver-ification, a process that presents the10 low-order hex digits of a SHA-1hash of the root certificate to therecipient of the root certificate. Therecipient can then contact the ownerand ask him to repeat this sequenceto verify the just-received root certifi-cate’s origin.

Finally, in a method equivalent tosecurity as it is on today’s Internet, apeer group can use a well-known CAto issue certificates, and the CA’s rootcertificate will be again part of thepeer group’s binary.

This simple approach employs exist-ing public-key and digital certificatetechnologies without conceptualchanges,an all-important requirementfor quickly gaining trust in ProjectJXTA’s approach to security.

T he JXTA framework’s key ben-efit is its ability to provide secu-rity via well-understood, trusted

approaches. Likewise, JXTA’s trans-port protocol independence letsapplications avoid the securitybreaches imposed by gateways orother network infrastructure.

Project JXTA has now completedJ2SE and J2ME MIDP implementa-tions.The latter is for small-footprintdevices like mobile phones. A Cimplementation is nearly completed.These three are edge-to-edge inter-operable and thus will provide JXTAP2P functionality across the devicespace. At JavaOne 2002, held in SanFrancisco during March, developersdemonstrated group instant messag-ing among mobile phones, laptops,and desktop systems with firewall tra-versal, using the JXTA protocols. �

William Yeager is Project JXTA ChiefTechnology Officer. Contact him atyeager@sun.com.

Joseph Williams is Chief Architect,Americas, for Sun Microsystems’iPlanet Professional Services group.Contact Williams at joseph.williams@sun.com.

The information presented here repre-sents the authors’ opinions and notnecessarily those of Sun Microsystems.

Memberssave 25%

on all conferences sponsored

by the IEEE Computer Society.

Not a member?

Join online today!

Memberssave 25%

on all conferences sponsored

by the IEEE Computer Society.

Not a member?

Join online today!

computer.org/join/