The token aggregation protocol as presented in Section 3.5 has a security weakness. The trusted peer creating the new tokens can create any number of new tokens. The aggregating peer might bribe the trusted peer in order to get additional tokens. In order to avoid this, a simple solution could be applied. The foreign tokens that are to be aggregated are sent to all quorum peers. They will verify that the number of new tokens created is correct. However, this is expensive in terms of the required traffic, as the complete foreign tokens are required to be sent. The quorum peers are required to check the signatures to validate the tokens. Furthermore, the quorum peers should also check for double spending. A second approach that produces less traffic uses the organisation of the trusted peers in a separate overlay. The idea is to use a step of indirection to conceal from the aggregating peer the trusted peer that is creating the new tokens. The aggregating peer should not select the trusted peer that is creating the tokens, nor should it be able to influence the selection. Therefore, a process that randomises the selection of the aggregation peer and the quorum is integrated in the protocol.
4.4.1 Protocol Details
The secure token aggregation protocol starts like the normal aggregation protocol. The swapping peer SP sends the tokens it plans to aggregate for new own tokens to a random trusted peer T P1 of its choices (step 1). However, because SP chooses this peer, it cannot be trusted. For example, SP could have bribed T P1. Therefore, T P1 will forward the tokens to another randomly selected trusted peer T P2. The challenge is, that the random selection must be verifiable in a later step of the protocol. Otherwise, SP could simply select a colluding peer. Thus, in step 2 T P1will contact SP ’s account holder set by sending a request_account_stamp-message. Each peer in SP ’s account holder set will receive the message and will calculate a hash value hSP of the current account information. This hash value is random and its result cannot be influenced, as the content it is created from is fixed for this point of
TP1 TP2 3 1 4 SP Account Holder Set for SP 2
Figure 4.5: Secure token aggregation protocol - part 1
time. Using Algorithm 4.13 described in Appendix D.2.1 the account holder set locates the next trusted peer of hSP in the system overlay. If it is T P1 (the peer it received the request_account_stamp-message from), it inverts the result and repeats Algorithm 4.13. The resulting trusted peer is T P2. T P2is called the aggregation administrator. The account holder set is responding to T P1with T P2’s peerID.
T P1receives T P2’s peerID and forwards SP ’s aggregation request to T P2(step 3). T P2will calculate how many tokens SP should receive and create this number of fresh tokens (step 4).
Now, like in the normal token aggregation protocol, T P2sends the new tokens’ issuing information to SP’s account holder set (step 5). The account holders will check if the message was sent by the peer they selected before as T P2. If not, they will file a reputation report against the sender. Otherwise, the account holders add the tokens to the account with the remark “preliminary”, because it will be confirmed later by the quorum that these tokens are correct.
In step 6 T P2will send the fresh tokens to the quorum in order to let them partially sign. Equivalent to selecting randomly T P2, in this step it is also crucial that the quorum be selected randomly. For this purpose a hash of the account information is used. The account information has been updated with the new tokens. The resulting hash value is denoted h0
SP. In the response to the aa-write-request T P2sent to the account holder set in step 5, the account holder set will send a list of t trusted peers to SP2, where tis the quorum size. The quorum is selected by locating the t next trusted peers of h0
SP. The quorum peers are denoted QP1to QPt. In the quorum T P1and T P2may also take part, as the peers are selected randomly and the quorum as a whole can be trusted.
In step 6 T P2 sends the fresh tokens to the selected quorum peers. For a system with very high security requirements the responsibility of calculating how many new tokens should be created cannot be assigned to a single peer. In such application scenarios, the foreign tokens are also sent to the quorum peers. The quorum peers can now verify the number of new tokens created. The distribution of the foreign tokens to the quorum peers consumes a lot of bandwidth at T P2as the foreign token message is the largest message transferred in the token aggregation protocol and this message must be sent t times by T P2.
TP2 6 SP 6 6 6 QP2 QP1 QP3 QP4 Account Holder Set for SP 5 QP1-4 7 7 7 7
Figure 4.6: Secure token aggregation protocol - part 2
The quorum peers receive the fresh tokens and send the token IDs to SP ’s account holder set in order to verify the new tokens. The account holder set will only accept the verifications from the trusted peers it selected in step 5.
In step 8 the quorum peers sign the fresh tokens partially and send them to SP . SP will combine the token’s signature and create new own tokens.
The detailed algorithm is stated in Appendix D.3.1.
4.4.2 Trustworthiness Discussion
According to the assumption the token-based accounting scheme is built on, Sybil attacks (Dou02) and whitewashing can be successfully prevented. Therefore, this discussion concentrates on the remaining attacks by cheating and collusion. Because tokens are the means for controlling access to accounted resources and services, cheating and collusion have as their aim either the injection of forged tokens into the system or the double spending of tokens.
The secure token aggregation protocol offers the ability to select a random peer as aggregation ad- ministrator that will create the new tokens and the ability to select a random quorum that signs the new tokens. The randomness of the aggregation administrator selection can be verified by the quorum. The randomness of the quorum selection can be verified by the account holder set. This has the goal of making it sufficiently hard to create forged tokens.
When all mechanisms for enhancing the trustworthiness of the token-based accounting scheme are applied, there remain two different situations wherein a peer could defraud the system.
• The cheating peer’s account holder set is colluding and the defrauding peer has the knowl-
edge of the scheme’s private key. Here, the cheating peer can itself create tokens. However, in
order to inject these into the system, it requires a colluding account holder set that will omit the checks of the sender, and simply add the tokens to the cheating peer’s aggregation account.
• The cheating peer’s account holder set colludes and t trusted peers are colluding with cheat-
TP2 SP 8 8 8 8 QP2 QP1 Account Holder Set for SP QP3 QP4
Figure 4.7: Secure token aggregation protocol - part 3
set. The account holder set will omit the checking of the senders, and simply add the new tokens to the cheating peers aggregation account.
In both settings fraud can be detected if the account information is checked frequently and the trusted peers that were supposed to act as aggregation administrator or quorum are not colluding. It is assumed that the account information cannot be manipulated in a way that a hash collision is created that has the aggregation administrator and the quorum as result, which is valid as a secure hash function is assumed. Section 4.2 explained that a peer is not allowed to contact its account holder set and that the messages sent there are inspected by a number of other peers. Also, the location of the account holder set has a certain degree of anonymity and it changes frequently with joins and leaves of peers. Therefore, it is very hard for a peer to make its account holder set collude in the fraud.
Also, the key management protocols described in the next section aim at avoiding the system key from being compromised.