What still needs to be implemented

There are several missing features in our framework, which we list in this Section.

First of all, we have not implemented the EncryptForSIGMember algorithm: this algorithm could be used for instance to encrypt Facebook mails that are exchanged between users. However, encrypting messages posted on user’s Walls would require a

different algorithm. Indeed Facebook mails can be modeled as one-to-one communi-cations, whereas a post on a Wall follows a one-to-many pattern, and would require a different type of algorithm.

The SIGMembersHandshake algorithm can however be used to encrypt a different type of communications, namely chat events: indeed a chat is a synchronous one-to-one communication, perfectly suited to be secured by running a Secret Handshake first, agreeing on a key and using it to encrypt the sentences that are exchanged between the two users.

Another aspect that may require improvement is that simple base64 encoding is used to exchange cryptographic messages on Facebook. This choice gives raise to two issues: first, the OSN provider may refuse to be used to exchange binary unintelligible information over fields that are meant to exchange short text strings. If our framework were to become popular, Facebook would most certainly attempt to stop it by banning profiles that misuse these fields. Second, the fact that a user publishes base64’ed strings in the About Me section of his profile, may raise suspicions on the fact that the user may be a member of some group, although it can be showed that from an information security perspective, the information published therein does not leak any information on group membership. These two problems may be solved by using a different way of encoding the binary information, perhaps one that maps binary data to a plausible text in some language.

Finally, the way our application reacts to a successful or unsuccessful handshake can be extended. Indeed, in its current state, the application reacts as follows: the invitee is the first one to know if the inviter is a SIG member. The choice whether to accept or not the friendship is however still in the hands of the user. On the other hand, the inviter knows whether the invitee is a SIG member or not only after the friendship has been confirmed by the invitee. Potentially, a malicious invitee disposes of a window of time in order to access the inviter’s profile regardless of its membership. The application can be improved as follows: the inviter sets the access rights for the (still unverified) invitee to a very minimum. Then, when the friendship has been confirmed and the application receives a response as to the invitee’s membership, the application can either cancel the newly established friendship in case of a negative response, or enhance the access rights for the (now verified) group member.

7.6 Conclusion

In this Chapter we have focused on the problem of securing user interaction in online social network, mainly through the creation of self-managed user groups that hand out Credentials to their members. Then, secret-handshake based authentication and content encryption are used in the social network. To this end we have defined a set of requirements, sketched a security model, presented a framework of cryptographic protocols and introduced a proof-of-concept java implementation, working in the ever growing Facebook platform.

The step from design to implementation has raised interesting challenges. Indeed the protocol that we have presented may guarantee a degree Unlinkability of Users by exchanging one-time Credentials; the ad-hoc and threshold nature of the protocol can make this approach realistic, since it could be assumed that at any point in time, at leasttSIG managers are available and able to supply new Credentials. However, if we desire to use Facebook as a data transport medium for cryptographic messages, linking is by definition possible since upon joining the Facebook network, users are assigned a univocal profile identifier, which is carried at any message exchange. It is therefore interesting to notice that a protocol that in theory preserves a security property loses it once it is implemented on a given platform.

This work is also relevant for another aspect: it constitutes a significant real-life application for Secret Handshakes. It could be debatable that not every Secret Interest Group requires such high security requirements, but certainly – seeing how Facebook and other OSNs are becoming the arena for exchange of very sensitive and private information – we expect that this requirement will arise, and our scheme represents a first step towards meeting this requirement.

RFID-Based Supply Chain Partner Authentication

8.1 Introduction

The growing use of Radio Frequency IDentification (RFID) in supply chains brings along an indisputable added value from the business perspective, but raises a num-ber of new interesting security challenges. One of them is the authentication of two participants of the supply chain that have possessed the same tagged item, but that have otherwise never communicated before. The situation is even more complex if we imagine that participants to the supply chain are business competitors.

In this Chapter we present a novel cryptographic scheme that solves this problem.

In our solution, users exchange tags over the cycle of a supply chain and, if two entities have possessed the same tag, they can agree on a secret common key they can use to protect their exchange of sensitive business information. No rogue user can be successful in a malicious authentication, because it would either be traceable or it would imply the loss of a secret key, which provides a strong incentive to keep the tag authentication information secret and protects the integrity of the supply chain. The protocol presented in this Chapter shares some similarities with Secret Handshakes.

We provide game-based security proofs of our claims, without relying on the random oracle model.