Skip to main content

Re-introducing CBJX

7 replies [Last post]
thenetworker
Offline
Joined: 2003-06-13
Points: 0

Why?

In JXTA, the peer id is not centrally managed and id spoofing attack could happen on purpose or inadvertently. When that does happen, the entire system would be impaired or unable to function at all.

The solution:

The CBJX is an essential JXTA security component used to verify the sender's address and certificate and drop the messages that fail the verification. With the CBJX in place, the id spoofing attack can be completely avoided. The CBJX also attaches the sender's certificate to every single incoming message. That means the authentication service is a built-in feature thanks to the CBJX. Developers can use the endpoint filter listener API to build any security policies and authorization services.

Together with other JXTA security components such as signed advertisement and SSLEngine secure pipe, CBJX can help you build end-to-end P2P enterprise applications easily.

The signed advertisement, SSLEngine based pipe, and CBJX features are submitted right now to the Issue #103. If that generates enough interests, the features could perhaps be integrated into the next official release.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivarulz
Offline
Joined: 2007-08-17
Points: 0

Hi,

Can you explain a little bit how Security is achieved in JXTA? For example, what is PSE membership service for? What are signed advertisements? How can you ensure that the message you received is from the from who you think it is? How can you make sure that you send a message to the intended peer?
These things are vital for any sound application and CBJX or any other addition should make into the next release if the code is ready.

From my understanding:
- PSE Membership: allows a peer to join a group only if it has the necessary certificates.
- Signed advertisements: ensures that advertisement spoofing cannot happen. An advertisement can be overridden only by the peer that published it.
- CBJX: a peer makes sure that the message received is from the "real" sender peer.

I think a lot of the community members are keen of finding out more.

Adrian

thenetworker
Offline
Joined: 2003-06-13
Points: 0

First of all, some of my following explanation is based on the service pack in the Issue #103. The story of the detailed implementation could be very long, but the fundamentals are simple and straightforward.

In a nutshell, the PSE is the object to retrieve your certificate and private key protected by password based encryption. You can use your certificate and private key to accomplish the PKI-related tasks such as signing anything you want. That is where the JXTA security starts. The PSE has been significantly simplified. It is enabled by default. When you start the JXTA for the first time, your account (CBID peer id, certificate, key pairs, etc.) is automatically created. The subsequent start-up of the JXTA will challenge you for the password you used when your account was created. If the challenge-response fails, the JXTA will refuse to run.

Advertisements are represented internally by XML DOMs. The signed advertisements are built on Java XML Digital Signature. When an advertisement is signed, its internal DOM is actually signed. By default, every single advertisement coming out of your box is signed before being sent out to other peers, who must verify every single advertisement upon its arrival.

The databases (Lucene for full text search, Nux for XQuery) use the CBID peer ids as the keys when they make the advertisements persistent. So, advertisements published or cached by different peers will never interfere with each other because CBID scheme is governed by the peers' certificates. No distinct peers (distinct key pairs) could produce the same verifiable CBID peer id. That is the reason why the CBID is configured as default peer id format.

JXTA messages are high level abstraction of structured data. Before they are sent to the wire for transmission, they are converted to either byte buffers or a data stream. After they are received, the byte buffers or the data from the stream are converted back to the messages. The digital fingerprinting happens before the data hit the wire, and verification after the data are received. That guarantees authenticity of all the messages. The useful outcome of the verification process is saved as properties of the messages. When they eventually reach the endpoint service and endpoint router, they will have enough security information from the message properties to make whatever security decisions. In the case of CBJX, the security decision happens to drop the messages if they fail the verification.

ivarulz
Offline
Joined: 2007-08-17
Points: 0

>When you start the JXTA for the first time, your account (CBID peer id, certificate, key >pairs, etc.) is automatically created
Is this available in 2.5 or in the new 2.6? I do not use PSE at the moment. Security is on my plate in the coming month, and I use password membership service. I suppose this is available in 2.5 with PSE already. I need to read PSE tutorial example.

>By default, every single advertisement coming out of your box is signed before being sent >out to other peers, who must verify every single advertisement upon its arrival.
Will this be available in 2.6 or only if issues 103, 105, 107 make into 2.6?
I think this is fundamental for a real world application.
Also the RDV verifying advs is crucial.

Can you post a guide on what is enabled by default, and what needs to be done by the programmer to use these functionality-es?
For example I don't know how CBJX can be used.

Correct me if I am wrong:
PSE Membership Service is used to allow a peer to be part of a group.
The other mechanisms, like CBJX, signing/checking advertisements, signing/checking messages are very useful if malicious things are intended by a peer who already can connect to the group.

Adrian

thenetworker
Offline
Joined: 2003-06-13
Points: 0

The PSE is in the 2.5. But it is not configured as the default membership service. You need to find the tutorial somewhere else. I don't have one in hand.

All other features are only available in the issue tracker at this moment. I won't post any guides until the features are released officially. As far as CBJX is concerned, it needs zero configuration. When you start the JXTA, it will be automatically protected.

JXTA membership service is a misnomer. It would be better to call it authentication service. It really just establishes a peer's credential. The membership service most people are talking about is actually authentication service plus authorization service, which JXTA does not offer as an out-of-box feature. Although it may sounds obvious, I suggest you think twice about what "be part of a group" actually means. The PSE basically states that whoever owns an X.509 certificate is "part of a group". It seems to be a peculiar way how a member is defined. But it is actually one of the best ways to define a member in an open P2P network such as JXTA.

The password membership service is an old school concept originated in the client server architecture and I believe it is there for demo and education purposes only, because you have to establish and centrally manage some kind of challenge-response mechanism. That is not the quintessential way of doing business in a P2P environment.

ivarulz
Offline
Joined: 2007-08-17
Points: 0

Thanks for the reply. Things are pretty clear.

My request would be you to follow up after the issues are resolved and the code makes it into the release.

I am aware of the Password Membership being for demo only. I did not address the security aspects in the project yet. Coming next month.

Adrian

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

I too would be very interested in any developments here.

Also not sure if you had any thoughts on denial of service attacks in JXTA?

thenetworker
Offline
Joined: 2003-06-13
Points: 0

You may present some hypothetical DoS scenarios to test the JXTA. To my knowledge, I have already avoided all imaginable DoS attacks. But I understand there is always room to improve.