Tutorial 2009-12-30

Requirements

Required modules

  • SPADE (included);
  • Tkinter;
  • python-dns.

Configuration

cedric@debian:~/pyChatter/source/spade$ python configure.py spade_platform_address

Initialization

Launch the SPADE platform:

cedric@debian:~/pyChatter/source/spade$ python runspade.py &
cedric@debian:~/pyChatter/source$ python authenticationAgent.py &

And the clients:

cedric@debian:~/pyChatter/source$ python2.5 simpleGui.py --name Bob --ontology ontoBob &
cedric@debian:~/pyChatter/source$ python2.5 simpleGui.py --name Alice --ontology ontoAlice &
cedric@debian:~/pyChatter/source$ python2.5 simpleGui.py --name Oscar --ontology ontoOscar

Later these parameters will be settable thanks to the user interface.

Screen shots

Registration of the clients

tuto20091230-1.png

The only service registered in the directory facilitator is the authentication agent. The authentication agent is in charge of serving requests of clients
Responsibilities:

  • manage the XML file of known client agents;
  • provides informations (ontology, public key) to a client about an other client;
  • in the future will be responsible of the CHAP authentication.
tuto20091230-2.png

After having launched the three clients, two kind of services are now present in the directory facilitator (as shown above). The new service "client_agent" is the service of all clients. To find interlocutors, it just to search clients registered in the service called "client_agent".

tuto20091230-3.png

This step is crucial to share the needed informations (RSA public key and ontology) with the authentication agent.

tuto20091230-4.png

After the registration of the three clients, the XML file of the authentication agent looks like this:

<?xml version="1.0" ?>
<clients>
    <client>
        <name>bob</name>
        <password>8e59a08ba401da8aedd958b3a65c2d8e70dc8da2</password>
        <ontology>ontoBob</ontology>
        <pubkey>30359838860767610757091542091279266839085374405037347831610630416264701652413-34854772007795029096804694320586401378720031977293239547990316835288384188043</pubkey>
    </client>
    <client>
        <name>alice</name>
        <password>5ed25af7b1ed23fb00122e13d7f74c4d8262acd8</password>
        <ontology>ontoAlice</ontology>
        <pubkey>20754369126658414961305546871593174119084408426524223847222155857355080176511-36469413097922204017047247774284748205354482251894336655158075210674199970427</pubkey>
    </client>
    <client>
        <name>oscar</name>
        <password>a4c7f167498cb7509519c18a2c3ef3eb0c986d29</password>
        <ontology>ontoOscar</ontology>
        <pubkey>6547208862562172060488483448951817168055283559286967501503728266901071862479-17299735995205685836084385590775243681302415493151597803962524142765524073923</pubkey>
    </client>
</clients>

Thanks to this file the authenticator is able to provide to Bob the RSA public key (and ontology) of Alice.

Selection of interlocutors

tuto20091230-5.png

By selecting Bob and Alice, Oscar will automatically and in a transparent manner retrieve the RSA public keys of Alice and Bob.

tuto20091230-6.png

Now Oscar is able to encrypt messages destined to Alice and Bob with the appropriate RSA key. Alice and Bob will decrypt the message with their private key.

tuto20091230-7.png

Now Bob is alone as we can see in the browser (DF) and with the Tkinter interface.

Generation of new RSA key

tuto20091230-8.png

If Bob generates a new RSA key, for the moment he has to manually publish the new one. This functionality will be implemented later. As you can see above, Alice has encrypt the message with the old public key of Bob. So, Bob is not able to decrypt the message.

Oscar has not published his public key

tuto20091230-9.png

Here the nasty Oscar has not published his public key. So even if Bob accepts the invitation, Oscar will not be added to Bob's interlocutors list. Bob is safe!

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License