A lightweight electronic signature scheme using Twitter

Transcription

1 A lightweight electronic signature scheme using Twitter Francesco Buccafurri, Lidia Fotia, Gianluca Lax, Serena Nicolazzo, and Antonino Nocera DIIES, University Mediterranea of Reggio Calabria Via Graziella, Località Feo di Vito Reggio Calabria, Italy Discussion Paper Abstract. In many application contexts, qualified electronic signature are difficult to adopt due to cost and technological reasons. As the European legislation admits the use of (non-qualified) electronic signatures in several cases, the design of new signature protocols with cheapness and usability features is a challenging issue. In this paper, we propose a new lightweight electronic signature protocol that does not require any public key infrastructure, cryptography and dedicated device, yet guaranteeing a good level of security. The protocol is conceived for closed domains of users, such as the case of documents exchanged between employees of a company. Signature and verification processes rely on the Twitter social network and do not require any changes of its features. A system prototype has been also designed and implemented to show that the adoption of our solution is both realistic and effective. 1 Introduction Qualified electronic signature is certainly the basic tool of any digitalization process, where exchanging documents with full legal validity has a significant role. This is, for example, the case of dematerialization process occurring in the Public Sector, where paper documents should disappear and long-term traditional archives should be digitalized by ensuring authenticity and integrity of documents by means of qualified electronic signature. In general, we expect that in e-government applications, and also in transactions between citizens and companies, the use of qualified electronic signature will always be increasing in the next future. However, there are some aspects that limit the diffusion of electronic signatures. These aspects are of two types: related to the cost and related to the usability of qualified electronic signature. Indeed, the cost of smart cards or of those services allowing remote signing called Hardware Security Modules [19, 24] A preliminary version of this paper appears in Proceeding of Electronic Government and the Information Systems Perspective (EGOVIS 2014) [10]

2 is certainly not negligible. Moreover, the invasiveness of the operations related to signing, verification, registration and certificate management is relevant. On the other hand, when we limit the application scope to specific cases in which the European legislation allows us to use simple (advanced) electronic signatures, designing new signature protocols that relax the heaviest features of qualified electronic signature in favor of usability and cheapness, is a timely and important issue. According to the Italian legislation [3, 5], this is the case, for example, of closed domains, where electronic signatures are applied to document exchange between municipal public offices and registered citizens, university and its students, or private company and employees. In these cases, advanced electronic signature can be adopted. Advanced electronic signature is technology-neutral, so that it does not refer to any technology. As required by the EU legislation [2], technological constraints of qualified electronic signature can be relaxed, included the presence of qualified certificate, provided that the solution satisfies the following properties: (1) it allows the identification of the signer and the unique connection of her/him to the signed document, (2) such a connection is created by using means that the signatory can maintain under her/his exclusive control, and (3) it allows us to detect if the data has been modified after the advanced electronic signature is applied. Evidently, the security of any advancedelectronic-signature solution must be evaluated from time to time, possibly by accredited bodies (for example, Agenzia per l Italia Digitale [1], in Italy). In this paper, we propose a new lightweight e-signature protocol with a good level of security, not using public key cryptography and dedicated devices. The protocol is conceived for closed domains of users, and can be configured in such a way that it falls into the scope of the Italian advanced electronic signature because properties (1) (3) are guaranteed. However, its application can be universal, either with enforceable-against-third-parties legal value in those Countries where the EU directive [2] was transposed, such as Italy, or in C2C, B2B and B2C private transactions where all parties agree. As social networks are used for disparate purposes [12, 13], in our protocol signature functions are spread out over the popular social network Twitter, without requiring changes of its features. By a prototype implementation, we show that the adoption of our solution appears both realistic and effective. Finally, we remark that, differently from other proposals existing in the literature (e.g. [14, 15]), based on PKI, conditional signature [17, 7], weak signature[23, 22], or visual criptography[21, 20, 18], our proposal is cheaper and less invasive because it does not rely on certification authority, asymmetric cryptography, or signature device. The paper is organized as follows. In the next section, we define the social signature and describe how it is generated and verified. In Section 3, we analyze the security of our signature protocol. In Section 4, we briefly discuss the implementation of our solution and, finally, in Section 5, we draw our conclusions. 2

3 2 Social Signature In this section, we define the social signature and we describe how it is generated and verified in closed domains of users. Indeed, in these scenarios, social signature responds to the necessity of a lightweight procedure to guarantee integrity and authenticity of documents created by (selected) people. Like a digital signature, a social signature allows us to be aware of the identity of the person who created an electronic document (a text file, an image, a video, etc.) and to ensure that this document has not been altered since its creation. Differently from digital signature, a social signature does not rely on a certification authority, asymmetric cryptography, or signature device such as smart card or USB key. As the name suggests, the solution is based on the use of the famous social network Twitter. Indeed, our signature protocol requires that each entity involved in the procedure has a Twitter profile. Now, we describe how social signature procedure works by referring, as a concrete scenario and w.l.o.g., to the closed domain of a company that adopts social signature in the documents exchanged between its employees. Thus, the two entities involved in our scenario are: 1. The company, which overviews the whole signature procedure and ensures the resolution of any possible dispute related to the signature (e.g., signature repudiation). 2. A domain of employees (generally including all the employees of the company) who use social signature to provide integrity and authenticity of the documents they create, and to verify integrity and authenticity of documents created by other employees of the same domain. To use social signature, all actors have to carry out the Registration procedure, which works as follows. Registration. First, the company creates an account on Twitter. Clearly, this is done by a person who is authorized to act on behalf of the company. Let us assume that the username chosen for the account on Twitter Next, the employees of the company, selected to use social signature, also create an account on Twitter. Suppose that an employee Name Surname as username. It is not required that all employees complete their registration on Twitter before social signature can be used (clearly, only registered employees can socially sign a document). However, it is possible to extend the domain with other employees at any time. Each time an employee, who was selected from the company to use social signature, completes its registration on Twitter, declares a following relationship and vice versa becomes a follower of the employee account). In this phase, the company is responsible of the verification of the employee identity. tweets the message #X is Y, where X (which is hashtagged) is the username of the registered employee and Y is an information identifying the employee. Y is typically the name and surname of the employee; however, further information, such as the employee id, is added to manage cases of homonymy. 3

4 The employee completes this phase by tweeting the message I am an employee of #Company (i.e., the username of the company hashtagged). As it will be clear in the following, the above message exchange is not just syntactic sugar, but has a precise role in the signature procedure. Finally, the employee receives the software that is used to generate social signatures. This software is installed on the computer and/or notebook used by the employee. As we will show in the following, this software accesses public data contained in Twitter by exploiting Twitter APIs. Once an employee has completed the registration procedure, he is enabled to create a social signature on a document with scope and validity relevant to the working domain. This is done by the procedure described below. Signature generation. First, the employee runs the social signature software and selects the file to sign. Thereafter, the signer is prompted to enter his Twitter username and password. The signature software computes the hash of the file by the cryptographic hash function SHA-256. Let H be the hexadecimal representation of the resulting digest. Now, the software allows the user to post the tweet I have signed the document #H, which is shorter than 140 characters (i.e., the maximum tweet length). In this receives the tweet and then tweets the has signed the document #H. We call confirmation tweet this message. Any employee or the company itself can verify the social signature generated by an employee through the procedure described below. Signature verification. This procedure returns the list of employees who have signed a given document and is carried out again by a software application. First, the user selects the file whose signature has to be validated. Then, the software computes the hexadecimal representation H of the digest of the selected file by means of SHA-256 and search for the tweets with hashtag #H. If no confirmation tweet from the company with the has signed the document #H is found, then the signature verification fails. Otherwise, the signature is considered valid and the identity of the employee who posted this tweet is returned. Observe that, more than one tweet (from different accounts) with this message can be found, this means that more employees have signed this document. 3 Security Analysis This section is devoted to the analysis of the features provided by social signature and to prove its robustness against a large number of real-life attacks. The assumption is that the attacker cannot add or compromise information shown on the Twitter accounts of the company and its employees. As a consequence, we implicitly assume that each actor keeps Twitter access password secret and that Twitter acts as a third trusted party. Observe that, in order to contrast attacks aiming to compromise the secretness of Twitter users password (like, for instance, attacks based on phishing or keyloggers), our protocol can be configured by using a stronger authentication on Twitter [4]. In our analysis, we consider given a document D with a valid social signature. 4

5 Document Authenticity. Social signature allows us to be aware of the identity of the signer of the document D. Indeed, in the verification procedure, the search for the tweet including the message I have signed the document #H (where, we recall H is the digest of the document) returns also the Twitter account, who sent this tweet. Then, a new search in the for the hashtag #X returns the tweet #X is Y, where Y is an information identifying the employee who signed the document (according to the registration procedure). Document Integrity. At the end of the signature, the document digest has been tweeted. Any change of the document produces a change of the digest, so that finding the tweet with the message I have signed the document #H does not return any result. Observe that, the attacker can modify the document in such a way that its digest appears on a tweet (for example, by cloning a document already signed). In this case, the message I have signed the document #H, where H is the digest of the altered document, is found but it is signed by (thus, associated with) an account not followed by the company. Non-repudiation. The signer may attempt to repudiate a signature by deleting the tweet generated during the signature procedure on his account. However, after this tweet is generated, it is confirmed by a new tweet from the company and always shown on the company account. As a consequence, the verification procedure is able to detect the repudiation attempt and to contrast it. Signature Timestamping. It is a nice feature to have the timestamp specifying when the signature is made. In digital signature, this is a (pay-) service provided by a third trusted party. In our case, the signature timestamp is directly provided by Twitter, which reports the time of generation of each tweet, and, thus, of the signature. Polymorphic files. The recent attack on digital signature based on the use of polymorphic files [16] is also contrasted. A polymorphic file includes two different contents, with different encodes, and the content shown depends on the file extension (see [8] for technical details). The solution already adopted for digital signature [9] consists in including the MIME Content-type of the document signed into the cryptographic message in such a way that the integrity of both the file extension is guaranteed. This solution can be applied also to our solution, thus making it resistant to this type of attack. 4 Implementation and technical details In this section, we briefly present the implementation of our proposal. It is composed of two independent modules, the former to sign a document and to verify a signature, the latter to implement the automatic generation of the confirmation tweet from the company. The first module has been implemented as a Web application and runs on a server equipped with Apache Tomcat Server. After the user selects the file to be signed (or validated), the SHA-256 cryptographic hash function of this 5

6 file is computed and represented as an hexadecimal string. Then, the generation of the suitable tweet posted on Twitter is performed by calling a particular link which is normally used to implement the Twitter share button. In our case, this link has the following structure: tweet?button_hashtag=h&text=ihavesignedthedocument, where the request parameter button hashtag is set equal to the document digest and the parameter text is set equal to the tweet text. In case of signature verification, the digest is used as hashtag to perform a Twitter search to find all the users who have generated a tweet with this hashtag. Observe that, this task cannot be performed by directly relying on Twitter s API [11]. Indeed, as specified in the Twitter s API documentations [6], search APIs do not return all tweets but only tweets from the past week. To solve this problem, in our system the search is performed through the Twitter Web interface. The search is carried out by calling the link com/search?f=realtime&q=h&src=typd and by parsing the HTML results of the query. As an additional advantage, the choice of using HTML parsing to handle this feature allows the overcoming of the Twitter API limitation rate. Our system extracts the IDs of the tweets having the document digest as hashtag, the screen-names of the users who posted them and the screen-name of the users mentioned in the tweet. The (confirmation) tweets generated by the company are processed and, by following the procedure described in Section 2, the account screen-name of the signers is obtained. Finally, the real name of the signers is obtained by searching for the company tweet linking the screen-name of an employee s Twitter-account to his real name. This search exploits the hash of the screen-name as hashtag (see Section 2). Concerning the second module, which is in charge of generating the confirmation tweet from the company, it is implemented as a Java application and runs as a Unix daemon under the YAJSW wrapper tool. It opens a new connection and associates a listener to the Twitter Streaming APIs. We built a filter allowing the listener to receive information coming from all the accounts in the list of the company followings. The list of followings is automatically retrieved through the Twitter Rest API GET friends/ids. Moreover, a trigger has been created in such a way to force a list update when a follower is add or deleted. Once a new tweet posted by one of the employees is filtered out, the daemon uses the same mechanism described above (i.e., Rest API POST statuses/update) to post the confirmation tweet. Observe that, our approach is not bounded by the usage of Twitter API rate limits. Indeed, Streaming APIs which are massively used by our system have not limits, whereas Rest APIs do have a limit but the rate is high enough because it is dimensioned to allow manually performed operations. The activities carried out by our system through Rest APIs are associated with user actions such as the addiction or deletion of accounts. 6

7 5 Discussion and Conclusion Social signature is a lightweight protocol that allows us to be aware of the identity of the person who created an electronic document and to ensure that this document has not been altered since its creation. Differently from digital signature, social signature does not rely on certification authority, asymmetric cryptography, or signature device. Our solution is conceived for closed domains of users, such as the case of document exchanges between citizens and municipal public offices or private companies and employees. We showed that our protocol is simple to implement because it requires just a signature software and does not need any additional infrastructure. The most secure configuration of the protocol requires that the existing Twitter strong authentication is enabled, but we guess that this feature does not add a relevant degree of invasiveness. Indeed, the signer does not have to manage devices, like smart cards, special PINs or passwords (besides the credentials used to access his Twitter profile), or certificates. Also the timestamping of the document is for-free. Moreover, the implementation cost of our protocol is nearly negligible, as it has been shown. Another strong point of our approach is that multiple signatures are implemented in a very easy and flexible way, with no need of planned exchanges of the document being signed, as it happens for PKCS#7 signatures. Acknowledgment This work has been partially supported by the TENACE PRIN Project (n P34XC) funded by the Italian Ministry of Education, University and Research and by the Program Programma Operativo Nazionale Ricerca e Competitività , Distretto Tecnologico CyberSecurity funded by the Italian Ministry of Education, University and Research. References 1. Agenzia per l Italia Digitale Directive 99/93/CEE. sessionid=tcsmt1ybq965grjtmg9gnfdxqqyp1w7y1lfllkwsmjvwry1q15fj! ?uri=CELEX:31999L DPCM 22 Febbraio _decreti_direttive/dpcm_22_febbraio_2013_-_nuove_regole_tecniche.pdf, Twitter authentication. in-verification-photos-and-more, Decreto Legislativo 7 Marzo 2005, n media/672080/dlgs aggiornato.pdf, Twitter.com API Documentation. tation,

8 7. I. Z. Berta, L. Buttyán, and I. Vajda. Mitigating the untrusted terminal problem using conditional signatures. In Information Technology: Coding and Computing, Proceedings. ITCC International Conference on, volume 1, pages IEEE, F. Buccafurri, G. Caminiti, and G. Lax. Fortifying the dalì attack on digital signature. In Proceedings of the 2nd International Conference on Security of Information and Networks, pages ACM, F. Buccafurri, G. Caminiti, and G. Lax. Threats to legal electronic storage: analysis and countermeasures. In Electronic Government and the Information Systems Perspective, pages Springer, F. Buccafurri, L. Fotia, and G. Lax. Social signature: Signing by tweeting. In Electronic Government and the Information Systems Perspective - Third International Conference, EGOVIS 2014, Munich, Germany, September 1-3, Proceedings, pages 1 14, F. Buccafurri, G. Lax, S. Nicolazzo, and A. Nocera. A Model to Support Multi- Social-Network Applications. In Proc. of the International Conference Ontologies, DataBases, and Applications of Semantics (ODBASE 2014), pages , Amantea, Italy, Springer. 12. F. Buccafurri, G. Lax, S. Nicolazzo, A. Nocera, and D. Ursino. Driving Global Team Formation in Social Networks to Obtain Diversity. In Proc. of the International Conference on Web Engineering (ICWE 2014), pages , Toulouse, France, Springer. 13. F. Buccafurri, G. Lax, and A. Nocera. A New Form of Assortativity in Online Social Networks. International Journal of Human-Computer Studies, 80:56 65, N. Buchmann, C. Rathgeb, H. Baier, and C. Busch. Towards electronic identification and trusted services for biometric authenticated transactions in the single euro payments area. In Privacy Technologies and Policy, pages Springer, M. S. Ferdous and A. Jøsang. Entity authentication & trust validation in pki using petname systems. Theory and Practice of Cryptography Solutions for Secure Information Systems, page 302, G. Lax, F. Buccafurri, and G. Caminiti. Digital document signing: Vulnerabilities and solutions. Information Security Journal: A Global Perspective, B. Lee and K. Kim. Fair exchange of digital signatures using conditional signature. In Symposium on Cryptography and Information Security, pages , T. Matsumoto. Human computer cryptography: An attempt. Journal of Computer Security, 6(3): , S. Mavrovouniotis and M. Ganley. Hardware security modules. In Secure Smart Embedded Devices, Platforms and Applications, pages Springer, M. Naor and B. Pinkas. Visual authentication and identification. In Advances in CryptologyCRYPTO 97, pages Springer, M. Naor and A. Shamir. Visual cryptography. In Advances in CryptologyEURO- CRYPT 94, pages Springer, T. Rabin. Robust sharing of secrets when the dealer is honest or cheating. Journal of the ACM (JACM), 41(6): , T. Rabin and M. Ben-Or. Verifiable secret sharing and multiparty protocols with honest majority. In Proceedings of the twenty-first annual ACM symposium on Theory of computing, pages ACM, L. Sustek. Hardware security module. In Encyclopedia of Cryptography and Security, pages Springer,