Distributed Light-Weight Authentication Model

For specific situations users can find the most appropriate system for their applications. For example, for a meeting in a room the password based key exchange method can be used, for a network defined by a hierarchy of trust relationships the resurrecting duckling policy is the best method. It can be said that none of these models is the best solution for low-value transactions in wireless sensor networks. Their proposed model is strongly based on human behavior. Here the human society can be seen as an ad-hoc network. They used the Distributed Trust Model [8] to establish trust relationships and extended it by a request for references. Each entity in the network stores a table of trustworthy entities from which paths between two entities can be found by using the tables of other entities. This type of algorithm is used for a self-organizing public-key system. The algorithm represents the threshold cryptography. In this type the compromised nodes can not harm the result of the operations if their number is below a threshold.

―The main purpose of the algorithm is not to make transactions really secure.

Actually the main goal is to make the attacker mostly get authenticated falsely‖ [9].

The node asks some common knowledge about a node to other nodes in the system. If no common knowledge is found a trust relationship can be derived using a trusted

third party. The CA or the mother duck can be used as a trusted third party according to the used algorithms (public key systems or hierarchical relationships). This model supports cooperation and feedback [9].

9.2.2.1 Description of the Proposed Model

If Alice wants to verify Bob’s identity, Alice starts asking Bob about common knowledge. This can be a secret key or a common knowledge about a recent transaction. Bob can prove his identity if there is some common knowledge. Otherwise, Alice starts asking to nodes taken from her list of trustworthy entities. In case possible return values can be ’yes’ or ’no’ to say it is Bob or not. Suppose Alice asks Cathy about Bob, she should first check Cathy’s identity by asking her about common knowledge (assuming that this transaction was encrypted) then Cathy looks if Bob is on her list of trustworthy people and checks his identity, or forwards Alice’s request in the same manner until an entity is found that knows Bob and can prove his identity. Once found the information is sent back to Alice, including all entities in the recommendation chain.

By using another algorithm Alice can ask about Bob’s identity to random entities. She might also ask Cathy and all other entities in the recommendation chain to do the same or Alice can ask Bob to give the devices that he has done transactions with recently. Alice can then ask these devices if they know Bob. Since Bob could easily set up the entities he gives as references, Alice can ask again her network of trustworthy entities if they know the references. A good reference would be an entity that has a relationship with Alice and Bob. When a link between Alice’s trusted network and Bob’s reference network is found a direct relationship between Alice and Bob can be setup. In this short chain the requests are sent out recursively [9]. Using both requests for recommendations and references the two trust networks are browsed starting at Alice and Bob until a connection is found. This keeps the number of involved nodes low. After Alice has received the results of her request she has to evaluate the data.

In the evaluation phase Alice decides if Bob is trustworthy or not. For more detailed systems the function might output an upper limit for a transaction value when dealing with Bob instead of ―yes‖ or ―no‖ answer. For data evaluation Alice can check the

that the result is not influenced by t or less malicious agents, where n is considerably larger than 2t [9].

For an (n, t) scheme, the algorithm requires that exactly n nodes respond and t/n*100% or less compromised nodes that respond cannot affect the result. A very suspicious person could configure its device such a way that it requires only ―yes‖ answers while less suspicious users would allow some errors.

Following an authentication of an entity, a secure channel can be initiated. A perfectly secure channel cannot be set up if there is no common knowledge between both entities. If encryption is going to be used Alice can send Bob a secret over the trustworthy path which is used to derive a relationship. Bob then sends back another secret using a random path. As a result Alice and Bob can derive a shared secret key by combining these secrets. Within this infrastructure only trustworthy entities can obtain the secret key by eavesdropping Bob’s answer.

For this kind of infrastructure the entity should participate in most of the requests and use its battery power and the devices that give recommendations can also expect to receive answers to their requests. Devices that never answer to any request will be removed from the list of trustworthy nodes or can be put on a list of untrustworthy devices [9]. This can be a simple punishment method. Furthermore entities might receive rewards for good recommendations. Finally a feedback method is proposed to make the system more robust. If Alice received from Dan via Cathy a positive recommendation about Bob’s identity, but then gets cheated by Bob, she can inform Cathy and Dan about their wrong recommendation. Also she can put Cathy and Bob on a list of untrustworthy devices. The reward and feedback methods give some quality and responsibility function to the algorithm.