Skip to main content

(PSE)MembershipService behavior

28 replies [Last post]
enygma2002
Offline
Joined: 2008-12-22

Hi friends!

I have reached the point where I have to implement security in order to provide private groups.

Previously ( http://forums.java.net/jive/thread.jspa?threadID=55389&tstart=0 ) I have resolved the issue of propagating objects to all the members of the group but now we must make sure that only peers that have the right credentials are currently members of the group.

This leads me to the MembershipService. This is the knowledge and understanding I managed to gather mostly by looking in the jxta source code.

*Please* correct me where I am wrong and I hope this can be useful for others facing the same lack of proper documentation of this section. I would also appreciate it if someone would confirm the information below. Also, if you know better/cleaner/faster and up-to-date ways of doing something stated below, please contribute.

1. The Keystore
The MembershipService uses a safe location to locally store the keys used to login into a group. This location is usually inside the local cache where Jxta keeps advertisements and such data. This location is also protected by a password set by the each peer in private. This password is used only to gain access to the protected information stored in the keystore.

2. The Keys
The keys are stored inside the keystore but are not in plain-text form. The keys themselves are encrypted with a password. In order to use a key, you have to unlock the keystore first using the keystore password and then to provide the desired key's password in order to get the decrypted desired key.

3. Creating a secure group
PSEMembershipService is the default membershipService in JXTA (AFAIK).
This means that there is no more the need to explicitly change the ModuleImplAdvertisement of a group and replace the "PeerGroup.membershipClassID" service parameter with a newly created ModuleImplAdvertisement that has the modulesSpecId "PSEMembershipService.pseMembershipSpecID" and describes the PSEMembershipService. This process is used in a really nice pse tutorial but I think can be skipped now (Jxta >2.5).
After doing the normal process of creating a group by first creating an AllPurposePeerGroupImplAdvertisement from the root group, you need to specify the PSE encrypted private key and certificate chain that will be used to authenticate peers that will want to join this group, including yourself.
How to do this:

EncryptedPrivateKeyInfo invitationPrivateKey = ...;
X509Certificate GROUP_ROOT_CERT = ...;
X509Certificate[] invitationCertChain = { GROUP_ROOT_CERT};

PSEConfigAdv pseConf = (PSEConfigAdv) AdvertisementFactory.newAdvertisement(PSEConfigAdv.getAdvertisementType());

pseConf.setCertificateChain(invitationCertChain);
pseConf.setEncryptedPrivateKey(invitationPrivateKey, invitationCertChain[0].getPublicKey().getAlgorithm());

XMLDocument pseDoc = (XMLDocument) pseConf.getDocument(MimeMediaType.XMLUTF8);

newPGAdv.putServiceParam(PeerGroup.membershipClassID, pseDoc);

Both the GROUP_ROOT_CERT and the invitationPrivateKey can be created with jxta shell. A quick look into the code of the jxta shell's command "pse.createkey" should provide the code to do that.
Now you can join and publish your newly created private group.

4. Group membership authentication
In order to join a group, you have to provide, as stated above:
- a password to unlock the keystore in order to access your credentials (collection of data containing a private key and a chain of private certificates).
- an identity - the peer you are claiming to be and for which you request access. This is an ID object so I suppose this will almost always be your current peer's ID (or the peer id withing the group you are trying to join - group.getPeerId()).
- a password for decrypting the private key stored in the keystore for the identity you just provided.

The code to do that:

StringAuthenticator memberAuthenticator = null;

try {
AuthenticationCredential application = new AuthenticationCredential(group, "StringAuthentication", null);

memberAuthenticator = (StringAuthenticator) membership.apply(application);
} catch (ProtocolNotSupportedException noAuthenticator) {
System.err.println("Could not create authenticator: " + noAuthenticator.getMessage());
return;
}

char[] keyStorePassword = getKeystorePassword();
char[] identityPassword = getIdentityPassword();
ID identity = group.getPeerID();
memberAuthenticator.setAuth1_KeyStorePassword(keyStorePassword);
memberAuthenticator.setAuth2Identity(identity);
memberAuthenticator.setAuth3_IdentityPassword(identityPassword);

try {
memberCredential = (PSECredential) membership.join(memberAuthenticator);

System.err.println("Member authentication successful.");
} catch (PeerGroupException failed) {
System.err.println("Member authentication failed: " + failed.getMessage());
return;
}

How it works:
- After getting the group's advertisement and creating a PeerGroup object, you get the group.getMembershipService().
- When getting the MembershipService, you make sure if it is a PSEMembershipSerivce (it is default, but just make sure).
- After you get the MembershipService it will automatically have attached to it the signed private key and a certificate chain (it was in the group advertisement of the group you want to join).
- The membership.join() method checks the memberAuthenticator for the required password.
-- It opens the keystore(or creates a new one if none existed?) with the keyStorePassword.
-- If it finds no encrypted key for the provided identity, it automatically creates one, saving the encrypted key from the groupAdvertisement for the provided identity.
-- It then call the memberAuthenticator.isReadyForJoin() which reads the encrypted key from the keystore for the provided identity and tries to decrypt it using the provided identityPassword.
-- If memberAuthenticator succeedes, you automatically join the peer group.

5. Using the private key
Jxta Programmer's Guide advises against using the private key directly. It states that certain mechanisms exist for providing common functionality without exposing the private key and keeping compatibility with keystore providers.
5.1 The only provided such mechanisms is PSECredentials.getSigner(String algorithm). This is nice for signing messages but what about encryption?
5.2 When using propagate pipes(like I do), message encryption or TLS is not provided by default like it is for SecureUnicast pipes. This means that I have to manually encrypt/decrypt my messages and for this I need the private key from the PSECredentials.getPrivateKey() to use with a symmetric key cryptosystem of my choosing.
5.2.1 Unfortunately, I see that in Jxta 2.5 the method PSECredentials.getPrivateKey() is deprecated and suggets the use of the getSigner()/getSignatureVerifier mechanism. For me, this could be a problem in future releases. What do you suggest?

Thank you very much and I await your feedback.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bondolo
Offline
Joined: 2003-06-11

SignedAdevertisement isn't a parent class it's a container. Normally it would be used in addition to the regular copy of an advertisement. ie. you get a peergroup or pipe advertisement then look up the cooresponding signed advertisement to verify that it's valid. yes, it is a little cumbersome. The alternative is to do as you suggest and put a signed copy of the important parts of the peergroup or pipe advertisement into a service params section. This is the technique currently used by the cbjx transport.

There was a proposal to add standard xml signing to jxta advertisements by "The Networker" but i don't believe it has been updated in quite a while. It would be nice if he could update it and prepare it for integration.

enygma2002
Offline
Joined: 2008-12-22

Thanks for your reply.

I will definitely check them out and maybe I will include this in my implementation.

enygma2002
Offline
Joined: 2008-12-22

> > 5. Using the private key
> > Jxta Programmer's Guide advises against using the
> > private key directly. It states that certain
> > mechanisms exist for providing common
> functionality
> > without exposing the private key and keeping
> > compatibility with keystore providers.
> > 5.1 The only provided such mechanisms is
> > PSECredentials.getSigner(String algorithm). This
> is
> > nice for signing messages but what about
> encryption?
>
> Which interface would you like? If you could suggest
> which JCE encryption API you wish to use I can try to
> suggest the best way to access it.
>
> > 5.2 When using propagate pipes(like I do), message
> > encryption or TLS is not provided by default like
> it
> > is for SecureUnicast pipes. This means that I have
> to
> > manually encrypt/decrypt my messages and for this
> I
> > need the private key from the
> > PSECredentials.getPrivateKey() to use with a
> > symmetric key cryptosystem of my choosing.
>
> True.
>
> > 5.2.1 Unfortunately, I see that in Jxta 2.5 the
> > method PSECredentials.getPrivateKey() is
> deprecated
> > and suggets the use of the
> > getSigner()/getSignatureVerifier mechanism. For
> me,
> > this could be a problem in future releases. What
> do
> > you suggest?
>
> The biggest reason it is deprecated and caution is
> recommended is because getPrivateKey() doesn't work
> when the keystore is a PKCS#11 (smartcard, etc.) For
> some cases the private key simply isn't available. I
> don't recall right now what the alternatives provided
> by JCE are.
>
> >
> > hank you very much and I await your feedback.
>
> Hopefully these hints help.

I would like to use the private key with a symmetric encryption algorithm like AES. From what I have read, jxta uses RC4 for symmetric encryption and so does SSL and such. I would prefer AES because I am familiar with its behavior but anyone will do as long as I can use the private key from the credential.

If you could tell me the proper way of doing this it would be great!

Thank you!

iiggoorr
Offline
Joined: 2008-09-22

Just for the update on my problem...

It was my mistake... I have forgotten about network and the fact that things can't happen instantly...

Now i everything is working OK, but time needed for RDV connection in a private group is about 20 seconds... I did it like this:

for(int i=0;i<30;i++) with i<15 it wasn't connecting :)
{
if(private.getRendezVousService().isConnectedToRendezVous())
break;
try
{
Thread.sleep(1000);
}
catch( );
}

well since you are taking time out my be I'll be able to help you for once :)...

Message was edited by: iiggoorr

Message was edited by: iiggoorr

enygma2002
Offline
Joined: 2008-12-22

Yep, I did suspected that: "Maybe we are calling those methods too early or at the wrong point in the process and the connection is made later on." ;)

None the less, we now both know how things work :)

Keep up the good work and let me know if you have other problems.

Good luck!

iiggoorr
Offline
Joined: 2008-09-22

hi, well as you know I have implemented solution given in this thread, and at first i thought that everything is working, but it isn't.

when i try to create secureUnicast connection i get SEVERE: Cannot get a TLS connection.

in my investigation of that error, i found out that only peer that created the peer group is joined with valid credentials.
Following code is executed,

if(memberAuthenticator.isReadyForJoin())
{
memberCredential= (PSECredential) membership.join(memberAuthenticator);
return memberCredential;
}

but memberCredential.isValid returns false, on all but creator of the group.

any Ideas?

THX.

iiggoorr
Offline
Joined: 2008-09-22

please forget about last message...

here is the explanation.

peer that created the group is on the server with public IP adress it is also RDV/RELAY for private group.

The time on that server is a bit messed up, so certificate is not valid right after issuing. Time on server is few hours early, so cert is valid after few hours :)

enygma2002
Offline
Joined: 2008-12-22

Glad to hear you figured it out!

Thanks for sharing! ;)

jtanago
Offline
Joined: 2008-06-18

Hi!

I've read the post and I've a doubt.

[i]pseConf.setCertificateChain(invitationCertChain);
pseConf.setEncryptedPrivateKey(invitationPrivateKey, invitationCertChain[0].getPublicKey().getAlgorithm());

XMLDocument pseDoc = (XMLDocument) pseConf.getDocument(MimeMediaType.XMLUTF8);

newPGAdv.putServiceParam(PeerGroup.membershipClassID, pseDoc);[/i]

In the code, you set an encrypted key as parameter of the group, but I don't understand why. Why is it necessary? Even, I see it as a security hole, if I have the key pair of a group I can issue identities to anyone. I think that I dont understant completily how would be the autentication of a peer in a group with a root cert. Thanks

enygma2002
Offline
Joined: 2008-12-22

Hi!

PSEMembershipService lets you join a group if you provide a password to decrypt an encrypted private key but first, it needs to obtain the encrypted private key.

This is why, to dynamically create secure groups, together with the peer group advertisement, you send the encrypted private key to a joining peer as a challenge. If the peer responds correctly to the challenge by decrypting the private key, he becomes trusted and can join the group.

As you can see, this is based on a symmetric key (the password used to encrypt/decrypt the group key).

This scheme offers the same level of access to all trusted members. The advertisements are published and discovered using the jxta protocols.

It is as safe as the symmetrical encryption algorithm that is used to encrypt/decrypt the group key and it does not need any (static) certificate authority (single point of failure).

Other variations can use certificate authorities, a hardcoded root certificate, etc. and can generate a certificate for each peer, possibly with different identities.

For my application, I did not need various identities for a group, like group admin, etc. so it proved to be a pretty good solution. Besides that, it was the only solution I figured out how to implement because the documentation does not show relevant samples of how to use the PSEMembershipService without hardcoded values, thus not relevant for the real world.

I would be happy to hear other solutions(possibly with implementation details) as well.

Cheers!

P.S.: I later on got confirmation on the fact that there is nothing stopping a peer from republishing a group advertisement for instance, overriding an existing one. Such an attack can disable other new, legitimate, peers from joining the secure group but would not compromise the security of the peers already in the group. Thus, any one of the existing peers in the group can republish the correct group advertisement and the security can be brought back to normal.

bondolo
Offline
Joined: 2003-06-11

> P.S.: I later on got confirmation on the fact that
> there is nothing stopping a peer from republishing a
> group advertisement for instance, overriding an
> existing one. Such an attack can disable other new,
> legitimate, peers from joining the secure group but
> would not compromise the security of the peers
> already in the group. Thus, any one of the existing
> peers in the group can republish the correct group
> advertisement and the security can be brought back to
> normal.

Another option is to sign the advertisements. Only legitimate peers can sign the advertisements so bad (unsigned) advertisements will be easy to detect and reject.

enygma2002
Offline
Joined: 2008-12-22

Yes, I forgot to mention that.

But I thought that signed advertisements were not yet introduced in jxta 2.5. It would seem that I am wrong according to https://jxta-docs.dev.java.net/jxse-javadoc/current/jxse/api/net/jxta/pr... but do normal PeerGroupAdvertisements subclass SignedAdvertisements? According to https://jxta-docs.dev.java.net/jxse-javadoc/current/jxse/api/net/jxta/pr... they don`t but IMO they should in future versions even starting with 2.6.

So, is using custom serviceParams the only option for signing PeerGroupAdvertisements in JXTA 2.5 (if that is possible at all)? What about PipeAdvertisements?

Thanks for the intervention bondolo.

jtanago
Offline
Joined: 2008-06-18

Thanks for your quick response enygma,

If I'm right, the encrypted private key is just a challenge and it hasnt other function that checks if a peer know the password, isnt it?

enygma2002
Offline
Joined: 2008-12-22

Yes, that is my intent for this proposed scheme.

Glad you cleared things out.

I am still waiting for bondolo's reply on my question above. That is quite interesting and could complete the proposed scheme in this thread.

jtanago
Offline
Joined: 2008-06-18

Hi!

I still have one doubt, why do you need a X509Certificate? Thanks for your time

enygma2002
Offline
Joined: 2008-12-22

Well, you create one from the start when you use PSEUtils.genCert. From it you get a private key and encrypt it.

You send the certificate, along with the encrypted private key because StringAuthenticator class in the PSEMembershipService requires it.

The most relevant part I see is:
synchronized public boolean isReadyForJoin() {
if (null != seedCert) {
return null != PSEUtils.pkcs5_Decrypt_pbePrivateKey(key_password, seedCert.getPublicKey().getAlgorithm(), seedKey);
} else {
return source.pseStore.validPasswd(identity, store_password, key_password);
}
}

The EncryptedKeyInfo instance you pass keeps just the algorithm used to encrypt the key, but does not keep the algorithm the key was constructed for (like AES, 3DES, etc.) so the certificate can help clear this out.
IMO, they could have used reflections or something similar instead of passing the certificate but there are at least 2 more places where it is used. Please check the sources.

iiggoorr
Offline
Joined: 2008-09-22

Hi enygma2002 , me again, well I am heaving strange problem, and hope you can help me once again...

The thing is it seems that my peers will not connect to RDV peer in my private group.

I know you had similar problem. Similar because I am using peer on a public address which my University gave me as a RDV/RELAY peer for the group. So it is a kind of seeding peer.

In net peer group everything is working OK meaning peers connect to seeding/RDV/RELAY.

then they join privateGroup which seedingPeer Created. That group is using PSE membership service, and peers also manage to join the group using that service.
My seeding peer is also joined in with PSE

The problem is :even though I start Rendezvous service on seeding peer for privateGroup with
privateGroup.getRendezvousService.startRendezvous
Edge pears doesn't seem to connect to it.

well it may be that I just don't know the instruction for making connection to RDV...

because waitForRendezvousConnection from NetworkManager class doesn't seems to do anything. It is probably because there is a connection with RDV in netPeeRgroup,
but if I do instruction

privateGroup.getRendezVousService().isConnectedToRendezVous()

the answer is false.

Question : do you maybe know how to make peers in private group to use RDV peers for that group?

THX very much for helping me so much.

enygma2002
Offline
Joined: 2008-12-22

Hello again!

Currently I have suspended my work with JXTA for more pressing matters, but I will resume it soon and can fill you in on my findings.

That being said, the problem I experienced with private group RDVs was that I could not discover the peers in the group. I was using the discovery service and, as it relies on RDVs and no RDVs were members of my group, I was getting no answer.

My solution was to make the peer that created the group a RDV and the rest of the peers that join the group make them autoStart when needed.
Now, if I try the discovery service to look for peer advertisements in my group, I got the desired result. The peers automatically used the RDV peer and I had to do no other configuration.

Now, If I understood your configuration correctly, you have a public RDV used to seed the network. It is also a member of the privatePeerGroup and you also made it a RDV for that group too.

If I remember correctly, the methods you tried gave me the same results, but the rdv actually worked and I could get peer advertisements. Why don`t you try the discoveryService and check it out. Maybe we are calling those methods too early or at the wrong point in the process and the connection is made later on.

So, try not to see if your rdv is connected, but if you can use it. (just an ideea)
Also, you could register a rdv listener for your group when you join it and see what's going on and if rdvs announce themselves.
Having edge peers with autoStart(true) is also a recommended thing for your groups. Note that the default check time is 5 minutes. you can modify that for your test purposes by using setAutoStart(true, interval_in_ms).

This is the best I can do right now since JXTA is not my top priority from now on for about a week or so.

Let me know how it works out.

Always glad to help when I can.

bondolo
Offline
Joined: 2003-06-11

> 1. The Keystore
> The MembershipService uses a safe location to locally
> store the keys used to login into a group. This
> location is usually inside the local cache where Jxta
> keeps advertisements and such data. This location is
> also protected by a password set by the each peer in
> private. This password is used only to gain access to
> the protected information stored in the keystore.

Doesn't matter. The keystore is protected by secure password based encryption. You could publish the keystore on a hacker web site and it would STILL be safe.

>
> 2. The Keys
> The keys are stored inside the keystore but are not
> in plain-text form. The keys themselves are encrypted
> with a password. In order to use a key, you have to
> unlock the keystore first using the keystore password
> and then to provide the desired key's password in
> order to get the decrypted desired key.

Correct.

> 3. Creating a secure group
> PSEMembershipService is the default membershipService
> in JXTA (AFAIK).

It is the default membership service for the NetPeerGroup and in FUTURE JXSE releases it will be the default for all JXSE peer groups. In JXSE 2.5 the NoneMembershipService is the default for all groups except the NetPeerGroup.

> This means that there is no more the need to
> explicitly change the ModuleImplAdvertisement of a
> group and replace the "PeerGroup.membershipClassID"
> service parameter with a newly created
> ModuleImplAdvertisement that has the modulesSpecId
> "PSEMembershipService.pseMembershipSpecID" and
> describes the PSEMembershipService. This process is
> used in a really nice pse tutorial but I think can be
> skipped now (Jxta >2.5).

After JXSE 2.5 this is true. One thing to remember is that ANY time you change the services specified in a ModuleImplAdvertisement you MUST change the ModuleSpecID for the Advertisement and the MSID for the group which will references it. Failing to do this will result in unpredictable behaviour because you will have the potential for multiple group definitions all sharing the same MSID. Which one gets used when you invoke a group will be random.

> 4. Group membership authentication

Seems correct.

> 5. Using the private key
> Jxta Programmer's Guide advises against using the
> private key directly. It states that certain
> mechanisms exist for providing common functionality
> without exposing the private key and keeping
> compatibility with keystore providers.
> 5.1 The only provided such mechanisms is
> PSECredentials.getSigner(String algorithm). This is
> nice for signing messages but what about encryption?

Which interface would you like? If you could suggest which JCE encryption API you wish to use I can try to suggest the best way to access it.

> 5.2 When using propagate pipes(like I do), message
> encryption or TLS is not provided by default like it
> is for SecureUnicast pipes. This means that I have to
> manually encrypt/decrypt my messages and for this I
> need the private key from the
> PSECredentials.getPrivateKey() to use with a
> symmetric key cryptosystem of my choosing.

True.

> 5.2.1 Unfortunately, I see that in Jxta 2.5 the
> method PSECredentials.getPrivateKey() is deprecated
> and suggets the use of the
> getSigner()/getSignatureVerifier mechanism. For me,
> this could be a problem in future releases. What do
> you suggest?

The biggest reason it is deprecated and caution is recommended is because getPrivateKey() doesn't work when the keystore is a PKCS#11 (smartcard, etc.) For some cases the private key simply isn't available. I don't recall right now what the alternatives provided by JCE are.

>
> hank you very much and I await your feedback.

Hopefully these hints help.

enygma2002
Offline
Joined: 2008-12-22

Thank you for answering!

>> This means that there is no more the need to
>> explicitly change the ModuleImplAdvertisement of a
>> group and replace the "PeerGroup.membershipClassID"
>> service parameter with a newly created
>> ModuleImplAdvertisement that has the modulesSpecId
>> "PSEMembershipService.pseMembershipSpecID" and
>> describes the PSEMembershipService. This process is
>> used in a really nice pse tutorial but I think can be
>> skipped now (Jxta >2.5).
>
> After JXSE 2.5 this is true. One thing to remember is
> that ANY time you change the services specified in a
> ModuleImplAdvertisement you MUST change the
> ModuleSpecID for the Advertisement and the MSID for the
> group which will references it. Failing to do this will
> result in unpredictable behaviour because you will have
> the potential for multiple group definitions all
> sharing the same MSID. Which one gets used when you
> invoke a group will be random.

So I have to create a new random MSID for the new group. I did not do that. Could this be the cause of the exception from here: http://forums.java.net/jive/thread.jspa?messageID=327254 ?

Message was edited by: enygma2002

enygma2002
Offline
Joined: 2008-12-22

Nope, I forgot I was already doing that like this:
newGroupImpl.setModuleSpecID(IDFactory.newModuleSpecID(PeerGroup.peerGroupClassID));

So this is not the reason for the exception.

Side Note: If I comment this line of code, I get a class cast exception from NoneAuthernticator to StringAuthenticatior when trying to authenticate. This is because the default membership service in the net peer group is none instead of PSE and, because I don`t change the MSID, I basically try ot auth to netPeerGroup and not the new group.

iiggoorr
Offline
Joined: 2008-09-22

Hi, I was wondering if suggested cod work for you, the thing is
although I have JXTA 2.5, it seems that the default membership service for newly created peer group is .membership.none.NoneMembershipService, and even worst is i don't know how to change it to PSE membership

enygma2002
Offline
Joined: 2008-12-22

Hi!

Some of the things in that post are wrong. I found that out later.

For instance, you are correct, the default MembershipService in the netPeerGroup is not PSEMembershipService as stated in documentation but it is NoneMembershipService and you have to explicitly set your new group to use it by modifying the ModuleImplAdvertisement. You also need to publish this by hand.

You also need to create a new peer group advertisement for your group and attach to it PSEConfigAdvertisement in which you fill in the certificate and encrypted private key that peers will have to decrypt in order to join the gorup. You also need to publish this by hand.

Having the peer group advertisement, you can create the PeerGroup using netPeerGroup.newGroup(newGroupAdvertisement).

I successfully created and joined secure group but, when I call netPeerGroup.newGroup(newGroupAdvertisement), a warning appears that it can not find the module impl advertisement for the group, even though I have created and published it earlier.

Another peer can see the group and join it but it will get the same warning.

The problem is that after joining with both peers, they can not see each-other inside the secure group and they can not even communicate (through propagate pipes).

If anyone can help, please do.

For code to do this, see: http://forums.java.net/jive/thread.jspa?threadID=56274&tstart=0

If anyone knows a better way to do this or a way that actually works, PLEASE HELP!

It does not say ANYWHERE exactly how to create a new secure group, it only says how to join one and all the sample code just uses hardcoded cases but none of them do not show how to do it in real life.

Again, please help.

P.S.: iiggoorr, please let me know if you have better luck. Thanks.

iiggoorr
Offline
Joined: 2008-09-22

Well thx for helping me, it seems we have the same problem, but you are one step in front of me.
I am implementing your solution, regarding group advertisement, and I I must say, it is simpler than one in programmer's guide.

I will inform you on my progress.

Now regarding your problem. You should maybe tray with solution where all peers use the same certificate for joining... In secure group communication is only possible with trusted peers, and trusted peers are peers wit certificate stored in the local key store.
Now since we don't have CA for distribution of certificates it could be good idea to use same identification for all peers, as long as only important thing is communication without possibility of ear doping, (crypted) and not who is communicating with you.

I am not sure if that would solve your/our problem, but it's worth a try.

enygma2002
Offline
Joined: 2008-12-22

All peers *do* use the same certificate in my example. The certificate is created by the peer that creates the group and then it is attached to the peerGroupAdv together with the encrypted private key.

UPDATE:

I have successfully discovered peers inside the secure peer group by making the peer that created the group to be a RDV for that group.

The problem was that there was no RDV for this peer group to handle peer discovery requests.

The problem that I am having now is that I would like JXTA to auto start rdvs when necesary and not make every peer that join a RDV itself. This could be done with the netPeerGroup.getRendezVousService().setAutoStart(true) but the peers [b]NEVER[/b] get promoted to RVDs. I don`t know why this is happening.

If someone could help I would be very grateful.

P.S.: Another weird problem I was having was that I could not see occasionally the created groups. This is due to the fact that I was using manager.setUseDefaultSeeds(true) and with one peer I was connecting to RDV A and with another peer I was connecting to RDV B. I was creating a group in RDV A but RDV B did not see the group and could not tell the second peer about it. Anybody have a clue about this?

enygma2002
Offline
Joined: 2008-12-22

See this: http://forums.java.net/jive/thread.jspa?threadID=56320&tstart=0 for fix.

Igor, with all this you should now be able to make it work as well.

Hope I helped you because no one helped me.

Good luck.

P.S.: If you are having problems along the way, maybe I can help you more. Feel free to ask here.

iiggoorr
Offline
Joined: 2008-09-22

Hi, enygma2002 well i have implemented your solution, and I am glad to say that it is working... peers can join my private group with pse membership.

Still I have one probably more theoretical question...

The thing is i don't understand how can it work meaning... all peers are using the same certificate to confirm that they are each peer with it's one ID.
So, that certificate is not saying that particular peer is peers A or peer B ...what is that certificate then saying?

Now from the practical side... Do you maybe know if I will be able to use SecureMulticastPipes with this solution? THX very much...

enygma2002
Offline
Joined: 2008-12-22

Glad it works for you too iiggoorr!

Make sure to have at least one RDV in the group or else peer discovery or propagatin messages will not work as I explained in my other messages.

Re the theoretical problem... well... you can not really trust peers inside JXTA only by certificates, mainly because there is no central authority. If you do include a central authority then you loose some P2P aspects and you become dependent on that server to be online or your network can not accept new peers.

> So, that certificate is not saying that particular peer is peers A or peer B ...what is that certificate then saying?

Actually... in this scheme it's not the certificate that's the most important, but the EncryptedPrivateKey. A peer can prove it's authenticity by decripting the encryptedPrivateKey with a provided password.
If you look at the code of StringAuthenticator.isReadyToJoin() you will notice that the encrypted key is decrypted with the key_password and if that succeeds then the peer can join the group.
You could say that, in this scheme, the certificate is created by the group creator and it identifies the group in a way that others can authenticate to it.

If you are using secureUnicastPipes, the credential resulted from the authentication to the group is used to sign/encrypt messages as well so if you try to skip or fake a step in the authentication, the rest of the group will ignore your messages.

I have not yet reached the point in my project where I need encryption. I will just rely on the security of MembershipService right now and implement encryption a bit later after I finish other priorities. I can let you know how it works out if you want.

> Now from the practical side... Do you maybe know if I will be able to use SecureMulticastPipes with this solution? THX very much...

:) This is what I am going to do with it as well. The down side is that there is no such thing as SecureMulticastPipes in JXTA for the moment.

You can read the reply(5.2) from bondolo on this thread right here: http://forums.java.net/jive/message.jspa?messageID=327122#327122 where he confirms the fact that you have to use the decoded private key of the group and symmetrically encrypt/decrypt your messages manually. I am waiting for a reply from bondolo for a propper way of doing this (as you can see further along in this thread).

Also multicasting is not reliable in JXTA. For a reliable way(with confirmations and all) see my thread: http://forums.java.net/jive/thread.jspa?threadID=55389&tstart=30 . I did not yet commit my work on jxtacast but I will as soon as possible. I have a not-so-much-but-tested-but-working version ready for my project.

Glad I can help. Feel free to ask more.

Good luck!