- Email: [email protected]
Long-term integrity and non-repudiation protocol for multiple entities
Sustainable Cities and Society 40 (2018) 189–193
Contents lists available at ScienceDirect
Sustainable Cities and Society journal homepage: www.elsevier.com/locate/scs
Long-term integrity and non-repudiation protocol for multiple entities a,⁎
Mohamad Badra , Rouba Borghol a b
T
b
College of Technological Innovation, Zayed University, United Arab Emirates Rochester Institute of Technology – Dubai, United Arab Emirates
A R T I C LE I N FO
A B S T R A C T
Keywords: Non-repudiation Data integrity Public key infrastructures Merkle tree
Smart cities aim at developing new applica-tions and architectures to improve the quality of urban services. However, privacy and security are still two of the technical issues that remain unsolved. The reason is that traditional solutions such as Public Key Infrastructures (PKI) were created to ensure some security services such as non-repudiation and data integrity. PKI enable the use of digital certificates and public key cryptosystems and require the cooperation among multiple entities to verify the certificates validity and to maintain a certificate revocation list. Due to the latest development in quantum computing, PKI-based solutions will not be able to provide continuous data integrity and non-repudiation. In fact, the techniques used by today PKI-based solutions to sign docu-ments are not future-proof. To address these drawbacks, we propose an efficient, lightweight nonrepudiation protocol for multiples entities that makes use of Merkle tree and of a Hash function that is futureproof. In contrast to PKI-based solutions, we demonstrate the efficiency of our proposed approach in terms of its low transmission and message overheads, and ability to maintain continuous data integrity and non-repudiation for smart cities’ applications and services.
1. Introduction Over the last few years, we have seen the emergence of a wide range of applications and technologies made possible by the significant improvements in hardware, software, and networking technologies. One of the chal-lenges that has emerged in most of today smart cities applications is the security and privacy of data being exchanged between the applications’ entities. In this optic, several security protocols have been developed (Kent & Seo, 2005; Rescorla, 2017) to mainly ensure data integrity and confidentiality, authentication, availability, and nonrepudiation. Non-repudiation and data integrity are particularly important in the context of smart cities services and applications. The aim of non-repudiation property is to ensure that individuals and organizations are unable to deny that they were the originator of an event or an action such as sending a message or making a bank transaction. Ex-isting solutions offer both the non-repudiation of origin (NPO) and the non-repudiation of receipt (NPR). The first guarantees that actions on resources or data cannot be denied by the subject performing them, whereas the second provides proof that the recipient is aware of the actions performed by the subject. Some of the existing solutions enable the use of public key infrastructures (PKI) and digital certificates (Cooper, Santesson, Farrell, Boeyen, Housley, & Polk, 2008) to guarantee both the NPO and the NPR. In this context, each party should have a digital certificate issued
⁎
by a trusted third party (i.e., certification authority) and contains the public parameters of the certificate’s owner such as the public key that is corresponding to the private key of the certificate’s owner. The certificate could be used to authenticate its owner, to exchange secret keys, and to guarantee non-repudiation features by digitally signing an action. For example, a user can sign a document by encrypting it using its private key. Upon receipt, the recipient uses the sender’s public key to verify the signature and to protect against the sender’s false denial of having signed the document. Next, the recipient should send an acknowledgment that is linked to the received document and signed using its private key, in which the sender verifies the recipient’s signature to protect against the recipient’s false denial of having received the document. The use of certificates has some critical limitations. In fact, it requires a PKI that must be well maintained. Further, it needs to establish a certificate chain between entities. Prior to verifying the sender’s signature, the recipient should verify all the certificates in the certifi-cate chain, except the first certificate, which is issued by the trusted third party. Next, the recipient checks whatever the sender’s certificate or any other certificate in the chain is revoked or not by consulting a certificate revocation list (CRL) that should be well maintained by a trusted third party (Cooper et al., 2008). Maintaining a PKI infrastructure is complex and normally more times and effort than an administrator wants to endure. The CRL list must be updated more
Corresponding author. E-mail addresses: [email protected] (M. Badra), [email protected] (R. Borghol).
https://doi.org/10.1016/j.scs.2017.11.023 Received 15 August 2017; Received in revised form 18 November 2017; Accepted 19 November 2017 Available online 07 April 2018 2210-6707/ © 2017 Published by Elsevier Ltd.
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
(Vigil et al., 2015), the Merkle hash tree goes a step further and reduces the integrity verification of a sequence of documents to the integrity verification of the root hash. By its design, this technology does not rely on any trusted third party. Hence, the evidence of existence is legally acceptable and could be verified by any party in case of dispute. In this case, parties need the authentication path of a given node in the Merkle tree to validate the node’s hashed content or to resolve any dispute. For a given node, the authentication path is the set of siblings of the nodes on the path from that node to the root of the tree. This process is called Merkle tree traversal (Jakobsson, Leighton, Micali, & Szydlo, 2003). At the lowest level of the tree, we found the leaves of the tree, where contents are hashed by each leaf before transferring the results to the parent nodes. At the inter-mediate nodes level, the hashes are derived from child nodes hashes. For example, in Fig. 1, h1 = h (h3 h4 ) . This technique is repeated by each intermediate node in the tree from the bottom up until reaching the root node; the obtained hash is called the root hash. For example, the root hash in Fig. 1 is h 0 = h (h1 h2) . The value h0 is therefore published in the hash calendar or in a widely witnessed media. As previously indicated, the content of a given entity can be authenticated with the root node and the corre-sponding authentication path information. For example, to verify h3, the verifier should have h0,h2 and h4, which form the authentication path. In this example, the verifier first computes h1′ = h (h3 h4 ) , then h 0′ = h (h1′ h2) and then compares h 0′ with h0 for equality.
frequently and can become quite large for a user to download. Due to the progress and advances in computer power (e.g., quantum computing) and in cryptanalytic tech-niques, most of the current cryptographic and signing algorithms will not remain valid long after current cryp-tographic algorithms are broken (Vigil, Buchmann, Cabarcas, Weinert, & Wiesmaier, 2015) and hence, these algorithms are not future-proof. With the emergence of new technologies such as cloud computing and Internet of Things (IoT), it becomes more challenging to improve the performance and scalability of PKIs. In this paper, we address the limitations of PKIs and we propose an efficient solution that is based on a Merkle tree (Merkle, 1987) to guarantee the non-repudiation and to provide continuous data integrity and users’ authentication. Our solution does not rely on certificates. Instead, it uses one-way cryptographic hash functions and secret keys to offer non-repudiation and to overcome the security issues and limitations discussed above. The rest of this paper is organized as follows. Section 2 presents the Merkle tree. We describe our non-repudiation approach and design in Section 3, followed by its security analysis and performance evaluation in Section 4. Finally, we conclude this paper in Section 5. 2. The Merkle tree A Merkle hash tree (Merkle, 1987) is a technique where every nonleaf node in the tree, from the bottom up until reaching the root node, holds the hash of the concatenated hashes of its child nodes (Fig. 1), resulting in generation of a root hash. The technique assumes that the root hash is shared in a trusted way; for example, a hash calendar (Buldas, Kroonmaa, & Laanoja, 2013) can be used to include the generated root hashes. The root hash is then used to efficiently verify the integrity of the contents of large data structures. A Merkle tree has been widely used in various fields of computer and network security. Recently, Keyless Signing Infrastructure (KSI) (Buldas et al., 2013), which is based on a Merkle tree, has been developed to ensure continuous data integrity of users’ transactions by periodically com-puting and publishing a root hash. It uses a Merkle hash tree to hash and timestamp the users’ transactions. The security of this technology does not deploy keys during the root hash generation. Hence, data authentic-ity and non-repudiation cannot be offered. Rather, this technology provides a proof of existence of any content that is hashed by a given node at a certain time. In fact, each root hash will be timestamped to prove that certain data was created at a specific time. The root hashes are linked timestamping, making backdating of the issued timestamped root hashes impossible without tampering the whole structure. Timestamp linking offers a verifiable and ordered link between the current and already issued timestamped root hashes. in other words, the current time-stamped root hash will prolong the proof of existence and integrity of previous time-stamped root hashes. Periodic publication of root hashes in widely witnessed media such as newspapers or a blockchain enhances transparency and protection against any mod-ification in the hashed content, and provides a proof of existence of a certain content. While the hash functions are used to reduce the integrity verification of large documents to integrity verification of short bit strings
3. Related works Several previous works have addressed the issue of multi-party nonrepudiation by using different tech-niques such as PKI-based solutions (Cooper et al., 2008), electronic notary (Lan, Xinping, Hanchun, & Jiancheng, 2016), trusted third party (TTP) (Caifen et al., 2002), IDbased non-repudiation (Kannisto et al., 2015), and so on. The authors in (Vigil et al., 2015) identified and analysis three types of solutions to provide long-time integrity protection and non-repudiation: timestamping-based, notarization-based and replication-based solu-tions. In this paper, we focus on the time-stamping-based solutions discussed in (Vigil et al., 2015), which are used to verify that a document existed at some point in time and to ensure the document’s integrity since its publication time. For more discussion on the advantages and drawbacks of these solutions, please refer to (Vigil et al., 2015). In Onieva, Zhou, and Lopez (2008), the authors describe the general multiparty non-repudiation problem, and discuss two main architectural categories: 1-n and n–n (where n is the number of participating parties). Recently in Kilin and Kp (2015), the authors describe a solution that requires O(n2) messages and a constant number of rounds. They demonstrate a superiority of their proposed solution in comparison to many existing solutions. As described later, our proposed solution requires O(n) messages. Moreover, our solution is based on the use of hash functions which are by far faster than the signature algorithms. Merkle tree by its sign does not provide neither authentication nor non-repudiation of origin/receipt. In parallel, most of the existing crypto-based solutions assume that there is no sudden break of cryptography. However, we have experienced attacks that can defeat some encryption cryptosystems such as RSA (Kleinjung et al., 2010). In the following section, we present our solution to combine Merkle trees and secret keys to provide continuous data integrity and non-repudiation for multiple entities. To the best of our knowledge, this is the first work of its kind available in literature. The authors in Jamthagen and Hell (2016) discuss some limitations related to the Merkle hash trees, particularly to the publication of root hashes in widely witnessed media to ensure continuous data integrity. They describe a publication layer based on the use of blockchain to publish the root hashes so they can be accessed by anyone and verified anytime. However, this approach inherits the blockchain limitations in terms of transaction fees, continuous stor-age increase, and of the
Fig. 1. Example of a hash tree with 4 leaves (depth = 2). 190
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
by e during a past round). Otherwise, the key k[e,i] should not be trusted by the third party.
security concerns described in Jamthagen and Hell (2016). The authors in Emmadi and Narumanchi (2017) describe an approach to ensure irreversibility and irrefutability of transactions already published in the blockchain. They propose using KSI as a complement to the blockchain to ensure the blockchain’s integrity without even monitoring it. In Vigil et al. (2015), the authors describe the use of a time-stamp authority (TSA) to issue signatures that are time-stamped as follows: each entity hashes its document and sends the result to the TSA, which creates a time-stamp and then signs the concatena-tion of the time-stamp and the hashed content it received from the entity, before transmitting the signature back to the entity. In our approach, the root hash is transmitted to every leaf in the tree and hence, the continuous data integrity is proved by means of a majority vote (i.e., replication) (Vigil et al., 2015) and of individual secret keys divulgated by each entity involved in the generation of the root hashes and verified by the receivers of the root hashes.
Since there is a finite number of secret keys that could be generated by each entity e at a given time, it may be possible for e to deploy all its keys when reaching a certain round r = ne − 1, during which the key k[e,1] is used by e. Now, e repeats the process described in the previous Section to generate a new individual secret key k[′e,0] , a new key vector V[′e, k] and a new synchronization vector Ve′. Both vectors are of a new size ne′. Then, e applies the hash function on both the keys k[e,0] and k ′[e, ne′] (e.g., H (k[e,0], k ′[e, ne′] ) ) and replaces k[e,0] with k[′e,0] . During the following round (i.e., r = ne), e divulgates k[e,0] so every third party can verify H (k[e,0], k ′[e, ne′] ) and then trust the new generated key k ′[e, ne′] when this latter is divulgated by e during the subsequent round.
4. Proposed solution
4.4. Lifecycle of the rounds’ references
In this section, we present our proposed solution to provide longterm integrity and non-repudiation for multiple entities. The proposed solution is based on forming a Merkle tree where the leaves are entities willing to sign a sequence of documents using individual secret keys. In the rest of this paper, we assume that each secret key is used for one time only. This can be verified by any third party during any round, as described later.
The number of rounds is encoded using a limited number of bytes (for example 2-bytes length or 216 rounds), leading to reset the roun’s counter to 1 and resulting in using the same counter for different rounds. However, this is not an issue since the root hashes are timestamped and it will be obvious to distinguish between the hashed contents generated by a certain entity by jointly using the time-stamps and the round reference. It is worth noting that, during a certain round r, it may be possible that some entities have contents to hash and some others have not. In this case, each entity having a content to hash will use the key that is corresponding to the round’s reference (e.g., r). Upon receipt of the root hash from the server, every entity will update the round reference and properly map between it and the reference of its last undisclosed key.
4.3. Key updating
4.1. Abbreviations and acronyms Table 1 summarizes the notations used in this paper. 4.2. Key initialization phase During an initial phase, each entity e (i.e., the server s and the tree’s leaves) generates an individual secret key k[e,0] that should never be divulgated to any third party, and generates a key vector, which consists of a certain number ne of individual secret keys, as follows:
V[e, k] = (k[e, ne − 1] ), k[e, ne − 2], …, k[e,1], k[e,0] )
(1)
k[e, i] = H (k[e, i − 1] ), 1 ≤ i ≤ n
(2)
4.5. Key revocation It is always possible for an attacker to compromise a device that contains the undisclosed keys. Our solution allows each compromised entity e to revoke its undis-closed keys or a subset of these key, so the attacker can neither pretend to be the entity nor send hashed content on its behalf. When e detects a key compromise at some point in time (i.e., between rounds r and r + 1), it will disclose both its last undisclosed key and its initial key k[e,0]. Any third party, including the server, will apply Eq. (2) to first verify that the key used by e during the previous round (i.e., k[e, ne − r ]) is generated from the key (i.e., k[e, ne − (r + 1)]) disclosed by e after it has been compromised, and that both the two keys are generated from k[e,0]. Next, the server revokes the undisclosed keys of e, and either updates the tree by removing e from the tree or validates the new key k[e, ne′] generated by e. It is worth nothing that the server will be able to confirm that k[e, ne − (r + 1)] is generated from k[e,0] by recursively applying Eq. (2) on this latter for (ne − r − 1) times.
Each entity e maintains a synchronization vector Ve = (1, 2,..ne). Each element in Vx is used as a reference to a generated secret key (i.e.,k[e,i] has the reference (ne − i + 1) that is corresponding to the round i). It is worth noting that a time-based reference could be used instead of the synchronization vectors, but this requires every entity to have an internal clock and more communication overhead to synchronize and validate the current time between the involved entities. When a third party receives, during the round i, a hashed content that is generated by e using the key k[e,i], it would verify that k[e,i] is generated from k[e,j] by applying Eq. (2) on k[e, j] (i.e., k[e,j] is divulgated
4.6. Root hash generation and publication
Table 1 Notations and definitions. Notation
Definition
e
Entity (server and users) The key vector of the entity e The synchronization vector of e The number of keys generated by e The key used by e during the round r Hash Function A root hash published by the server at round r A root hash generated by a root node at round r Concatenation Depth of the tree The length (bytes) of the hashed content using H
V
[e,k] V [e] n [e] k [e,r] H root_cal[r] root hash[r] ∣ d H.size
During each round r, the server s hashes, using its secret key k[s,r], the concatenation of the current root hash and the las root hash rooth _cal[r−1] previously published by the server (e.g., in a hash calendar), as follows:
roothcal[r ] = H (roothcal[r − 1] ) root hash[r ], k[s, r ] )
(3)
Next, the server divulgates its secret key k[s,r], so each entity will be able to: a) verify the existence of its hashed content by regenerating the roothash[r] using the authentication path it receives from its parent node, and b) check the integrity and the authenticity of the root_cal[r]. Then, each entity e divulgates its secret key k[e,re] that is linked to the round r and used to generate the hashed content of e. 191
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
Fig. 2. Example of the proof of existence of hashed content.
server the last key it generates. Any other key generated by e during this phase is unknown to any third party, including the server. The keys generated by e are linked one to the other (Eq. (2)) and the first key divulgated by e is the last key it generated. Hence, when e divulgates a key during a given round r, the server will apply Eq. (2) on the previous key divulgated by e to verify whatever it is derived from the key disclosed during the round r or not, and then to authenticate e and its hashed content transmitted to the server. It may be possible for an adversary to reuse a key that is already divulgated by e during a past round to inject false data. However, the server and any third party will be able to detect the adversary action because 1) any key should not be used more than one time, and 2) the hash of the key used by the adversary will not be equal to the hash of the last key divulgated by e. During a certain round r, only the entity e knows the key that is mapped to r (e.g., k[e,r]) and any other entity knows the key that is corresponding to k[e,r] (i.e., k[e,r−1]). Hence, during the round r, only e can generate a valid hashed content using k[e,r]. This is equivalent to the case when e signs a document using a digital certificate, in which the private key used to sign the document is not shared with any third party; only the public key corresponding to the private key is publicly available, so any third party can validate the signature using that public key. In our solution, everyone will be able to validate the hashed content once the key used by e during the round r is divulgated. After receiving the root_cal[r] from the server, the entity e cannot deny that it didn’t use k[e,r] to generate its hashed content and therefore, the nonrepudiation of origin is guaranteed. Our solution offers the non-repudiation of receipt as well. In fact, during the same round, the server s will generate rooth_ cal[r] using its last undisclosed key. Once this key is divulgated by the server, every entity will be able to verify rooth_cal[r]. As indicated Vigil et al. (2015), the expected lifetime of a hash function is usually longer than the expected lifetime of a signature algorithm. However, the security of hash functions is not everlasting. Choosing the appropriate hash function will depend on predicting the lifetime of that hash function. Generally, keyed-hash function is harder to break than a hash function (e.g., the case of HMAC-MD5 and MD5). Since our approach is based on the use of keyed-hash function, it is assumed to predict the lifetime of the keyed-hash function once the hash function itself is suddenly compromised, and then to replace the hash function with a more secured one. In contrast to the distribution of the hashes of both the authentication path and the root node, we leverage the benefits of the replication approach, which provides long-term integrity of document without
4.7. G. Proof of existence of hashed contents and of the root hash As previously indicated, each entity e generates its hashed content by applying a hash function on both its content and its secret key (e.g., he = H(content, k[e,i])). The hashed content is then transmitted to the entity’s parent node. Each of the intermediate nodes in the tree will hash the concatenation of the hashed contents it receives from its child nodes and transmits the result to its parent node, until reaching the root node, which then generates the root hash (see Fig. 2, phase 1). The server generates the root_cal[r] by applying Eq. (3) on both the root hash and the key linked to the current round. Next, the server sends root_cal[r] back to its child nodes, along with its key k[s,r]. Each intermediate node in the tree from the top down until reaching the leaves will forward any content it receives from its parent node to each of its two child nodes. In parallel, each intermediate node will send to its left (resp. right) child node the hashed content it previously received from its right (resp. left) child node. This will help in building the authentication path that is needed by each entity to validate the root_cal[r]. At this stage, each entity e generates the root hash by using the hashed contents of its authentication path and compares the generated root hash to the received roothash[r] for equality. If they are equal, then e will verify root_cal[r] by applying Eq. (3) on both k[s,r] and the concatenation of roothash[r] and the root hash it received during the previous round. If root_cal[r] is successfully verified, then e authenticates the server and accepts root_cal[r] as an evidence of existence for its hashed content. Now, e divulgates its key k[e,i] by transmitting it along with its hashed content to the server s (see Fig. 2, phase 3). Upon receipt, the server validates the hashed content of e using k[e,i]. 5. Security and performance analysis of the proposed solution In this section, we present a security and performance analysis of our proposed solution and we demonstrate its effectiveness in providing long-term integrity protection and non-repudiation of origin and of receipt as well. Moreover, we show that our solution is resilient to a wide range of attacks such as false data injection attacks and passive attacks. One of the attacks against data integrity if False Data Injection (FDI), in which the attackers intentionally change the data in a way that the receiver will be unable to detect forged or malformed data when collecting data from the origin. During the key initialization phase, each entity e shares with the 192
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
6. Conclusion
Table 2 Transmission and message overhead. Transmission
3*(2d+1 − 1)
Transmission (Optimized) Message overhead per entity
3*2d (d + 1)* H.size
In the context of smart cities, services are usually dis-tributed and their functionality is provided as the result of the interactions among several entities that are usually distributed across several computing devices. In this paper, we presented a long-term data integrity and nonrepudiation solution for multiples entities. Our scheme makes use of a Merkle tree and of sequences of secret keys to generate a time-stamped hashes that are authen-ticated and integrity protected. Moreover, our solution offers a continuous proof of existence of contents. We have demonstrated that our solution is efficient in terms of crypto-computational and communication overheads, and is designed to be more resilient to various attacks, including data forgery and data injection attacks. Finally, we argue that our proposed solution design is appropriate when resource-constrained devices are involved. As part of our future work, we will develop and test our proposed approach with different settings to validate its effective-ness and the accuracy of results it gives. Moreover, we will extend it to meet the requirements of multi-party contract signing architectures.
using cryptog-raphy and without using widely witnessed media such as newspapers or a blockchain. We used the following performance evaluation metrics in our performance analysis: 1) Transmission Overhead: this is the number of transmissions between the entities. 2) Message Overhead: this is the memory space used by an entity for storing information about a content, and the percentage overhead of different components (content, crypto-operations) in each operation. When all the leaves of a tree are at same depth d, the tree will contain N = 2d leaves. This is the maximum number of leaves of a binary tree of depth d. As for the authentication path that is needed to verify a root hash by each entity, it cannot exceed log2(N) = d hashes. In other words, the number of hashed values that should be stored by each leave during a certain round is d hashed contents. If we assume that the intermediate nodes are running on the server or on a dedicated host, then the number of transmissions required to generate a root hash is only 2d. A similar number will be needed to send the root hash, the server’s key and the authentication path to each leave in the tree. In addition, one transmission is needed by each entity when divulgating its key. Hence, a total of 3 *2d transactions are needed per each round. Table 2 summarizes the transmission and the message overheads per each round. We theoretically compare between our proposed solu-tion and the traditional PKI-based solutions in terms of performance efficiency and security features. In a PKI-based solution, each party needs to have a digital certifi-cate, verify each certificate in the certificate chain, and to consult the CRL as described above. The sender then signs its document using its private key, and the receiver will decrypt the sender’s signature using the sender’s public key, compute its hash on the received document, and then compare the two hashes for equality. Next, the receiver will sign a time-stamped hash of the received document and send it back to the sender, in which the sender will follow the same steps as the receiver to verify the receiver signature. In our approach, each entity will hash its document and verify (log2(N) + 1) hashes, which are the hashes generated by the entities in its authentication path. Each intermediate node in the tree will compute one hash. The server will verify d hashes and generate only one. During the key verification process, each entity will verify the key disclosed by the server by applying one hash (Eq. (2)), and the server will generate d hashes. Finally, the server will generate one hash when publishing the root hash in the hash calendar.
References Buldas, A., Kroonmaa, A., & Laanoja, R. (2013). Keyless signatures infras-tructure: How to build global distributed hashtrees. In H. Riis Nielson, & D. Gollmann (Eds.). NordSec 2013 (pp. 313–320). LNCS 8208. Caifen, W., Jianhua, G., Xinjun, D., Jin, Q., Tieshan, Z., & Shiyong, Y. (2002). A multiparty non-repudiation protocol with semi-trusted third party. Proc IEEE region 10 conference on computers, com-munications control and power engineering, 188–191. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., & Polk, W. (2008). Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile. IETF RFC 5280. Emmadi, N., & Narumanchi, H. (2017). Reinforcing immutability of per-missioned blockchains with keyless signatures’ infrastructure. Proc ICDCN. Jakobsson, M., Leighton, T., Micali, S., & Szydlo, M. (2003). Fractal Merkle tree representation and traversal. Cryptographer’s track at RSA conference, 314–326. Jamthagen, C., & Hell, M. (2016). Blockchain-based publishing layer for the keyless signing infrastructure. Proc IEEE conferences on ubiquitous intelligence and computing, advanced and trusted computing, scalable computing and communications, cloud and big data computing, internet of people and smart world congress, 374–381. Kannisto, J., Takahashi, T., Harju, J., Heikkinen, S., Helenius, M., Matsuo, S., et al. (2015). A non-repudiable negotiation protocol for security service level agreements. Int. J. Communication Systems, 28(15), 2067–2208. Kent, S., & Seo, K. (2005). Security architecture for the internet protocol. IETF RFC 4301. Kilin, H., & Kp, A. (2015). Optimally efficient multi-party fair exchange and fair secure multi-party computation. Proc CT-RSA, 330–349. Kleinjung, T., Aoki, K., Franke, J., Lenstra, A. K., Thome, E., Bos, J. W., et al. (2010). Factorization of a 768-bit RSA modulus. Proc CRYPTO, 333–350. Lan, L., Xinping, H., Hanchun, C., & Jiancheng, D. (2016). Non-repudiation scheme of smart home based on cloud service. Proc sixth international conference on instrumentation and measurement, computer communication and control, 453–456. Merkle, R. C. (1987). A digital signature based on conventional encryp-tion function. Proc CRYPTO. Springer Verlag. Onieva, J., Zhou, J., & Lopez, J. (2008). Multi-party non-repudiation: A survey. ACM Computing Surveys, 41(1), 1–49. Rescorla, E. (2017). The transport layer security (TLS) protocol ver-sion 1.3. IETF Proposed Standard. Vigil, G., Buchmann, J., Cabarcas, D., Weinert, C., & Wiesmaier, A. (2015). Integrity, authenticity, non-repudiation, and proof of existence for long-term archiving: A survey. Computers and Security, 50, 16–32.
193
Contents lists available at ScienceDirect
Sustainable Cities and Society journal homepage: www.elsevier.com/locate/scs
Long-term integrity and non-repudiation protocol for multiple entities a,⁎
Mohamad Badra , Rouba Borghol a b
T
b
College of Technological Innovation, Zayed University, United Arab Emirates Rochester Institute of Technology – Dubai, United Arab Emirates
A R T I C LE I N FO
A B S T R A C T
Keywords: Non-repudiation Data integrity Public key infrastructures Merkle tree
Smart cities aim at developing new applica-tions and architectures to improve the quality of urban services. However, privacy and security are still two of the technical issues that remain unsolved. The reason is that traditional solutions such as Public Key Infrastructures (PKI) were created to ensure some security services such as non-repudiation and data integrity. PKI enable the use of digital certificates and public key cryptosystems and require the cooperation among multiple entities to verify the certificates validity and to maintain a certificate revocation list. Due to the latest development in quantum computing, PKI-based solutions will not be able to provide continuous data integrity and non-repudiation. In fact, the techniques used by today PKI-based solutions to sign docu-ments are not future-proof. To address these drawbacks, we propose an efficient, lightweight nonrepudiation protocol for multiples entities that makes use of Merkle tree and of a Hash function that is futureproof. In contrast to PKI-based solutions, we demonstrate the efficiency of our proposed approach in terms of its low transmission and message overheads, and ability to maintain continuous data integrity and non-repudiation for smart cities’ applications and services.
1. Introduction Over the last few years, we have seen the emergence of a wide range of applications and technologies made possible by the significant improvements in hardware, software, and networking technologies. One of the chal-lenges that has emerged in most of today smart cities applications is the security and privacy of data being exchanged between the applications’ entities. In this optic, several security protocols have been developed (Kent & Seo, 2005; Rescorla, 2017) to mainly ensure data integrity and confidentiality, authentication, availability, and nonrepudiation. Non-repudiation and data integrity are particularly important in the context of smart cities services and applications. The aim of non-repudiation property is to ensure that individuals and organizations are unable to deny that they were the originator of an event or an action such as sending a message or making a bank transaction. Ex-isting solutions offer both the non-repudiation of origin (NPO) and the non-repudiation of receipt (NPR). The first guarantees that actions on resources or data cannot be denied by the subject performing them, whereas the second provides proof that the recipient is aware of the actions performed by the subject. Some of the existing solutions enable the use of public key infrastructures (PKI) and digital certificates (Cooper, Santesson, Farrell, Boeyen, Housley, & Polk, 2008) to guarantee both the NPO and the NPR. In this context, each party should have a digital certificate issued
⁎
by a trusted third party (i.e., certification authority) and contains the public parameters of the certificate’s owner such as the public key that is corresponding to the private key of the certificate’s owner. The certificate could be used to authenticate its owner, to exchange secret keys, and to guarantee non-repudiation features by digitally signing an action. For example, a user can sign a document by encrypting it using its private key. Upon receipt, the recipient uses the sender’s public key to verify the signature and to protect against the sender’s false denial of having signed the document. Next, the recipient should send an acknowledgment that is linked to the received document and signed using its private key, in which the sender verifies the recipient’s signature to protect against the recipient’s false denial of having received the document. The use of certificates has some critical limitations. In fact, it requires a PKI that must be well maintained. Further, it needs to establish a certificate chain between entities. Prior to verifying the sender’s signature, the recipient should verify all the certificates in the certifi-cate chain, except the first certificate, which is issued by the trusted third party. Next, the recipient checks whatever the sender’s certificate or any other certificate in the chain is revoked or not by consulting a certificate revocation list (CRL) that should be well maintained by a trusted third party (Cooper et al., 2008). Maintaining a PKI infrastructure is complex and normally more times and effort than an administrator wants to endure. The CRL list must be updated more
Corresponding author. E-mail addresses: [email protected] (M. Badra), [email protected] (R. Borghol).
https://doi.org/10.1016/j.scs.2017.11.023 Received 15 August 2017; Received in revised form 18 November 2017; Accepted 19 November 2017 Available online 07 April 2018 2210-6707/ © 2017 Published by Elsevier Ltd.
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
(Vigil et al., 2015), the Merkle hash tree goes a step further and reduces the integrity verification of a sequence of documents to the integrity verification of the root hash. By its design, this technology does not rely on any trusted third party. Hence, the evidence of existence is legally acceptable and could be verified by any party in case of dispute. In this case, parties need the authentication path of a given node in the Merkle tree to validate the node’s hashed content or to resolve any dispute. For a given node, the authentication path is the set of siblings of the nodes on the path from that node to the root of the tree. This process is called Merkle tree traversal (Jakobsson, Leighton, Micali, & Szydlo, 2003). At the lowest level of the tree, we found the leaves of the tree, where contents are hashed by each leaf before transferring the results to the parent nodes. At the inter-mediate nodes level, the hashes are derived from child nodes hashes. For example, in Fig. 1, h1 = h (h3 h4 ) . This technique is repeated by each intermediate node in the tree from the bottom up until reaching the root node; the obtained hash is called the root hash. For example, the root hash in Fig. 1 is h 0 = h (h1 h2) . The value h0 is therefore published in the hash calendar or in a widely witnessed media. As previously indicated, the content of a given entity can be authenticated with the root node and the corre-sponding authentication path information. For example, to verify h3, the verifier should have h0,h2 and h4, which form the authentication path. In this example, the verifier first computes h1′ = h (h3 h4 ) , then h 0′ = h (h1′ h2) and then compares h 0′ with h0 for equality.
frequently and can become quite large for a user to download. Due to the progress and advances in computer power (e.g., quantum computing) and in cryptanalytic tech-niques, most of the current cryptographic and signing algorithms will not remain valid long after current cryp-tographic algorithms are broken (Vigil, Buchmann, Cabarcas, Weinert, & Wiesmaier, 2015) and hence, these algorithms are not future-proof. With the emergence of new technologies such as cloud computing and Internet of Things (IoT), it becomes more challenging to improve the performance and scalability of PKIs. In this paper, we address the limitations of PKIs and we propose an efficient solution that is based on a Merkle tree (Merkle, 1987) to guarantee the non-repudiation and to provide continuous data integrity and users’ authentication. Our solution does not rely on certificates. Instead, it uses one-way cryptographic hash functions and secret keys to offer non-repudiation and to overcome the security issues and limitations discussed above. The rest of this paper is organized as follows. Section 2 presents the Merkle tree. We describe our non-repudiation approach and design in Section 3, followed by its security analysis and performance evaluation in Section 4. Finally, we conclude this paper in Section 5. 2. The Merkle tree A Merkle hash tree (Merkle, 1987) is a technique where every nonleaf node in the tree, from the bottom up until reaching the root node, holds the hash of the concatenated hashes of its child nodes (Fig. 1), resulting in generation of a root hash. The technique assumes that the root hash is shared in a trusted way; for example, a hash calendar (Buldas, Kroonmaa, & Laanoja, 2013) can be used to include the generated root hashes. The root hash is then used to efficiently verify the integrity of the contents of large data structures. A Merkle tree has been widely used in various fields of computer and network security. Recently, Keyless Signing Infrastructure (KSI) (Buldas et al., 2013), which is based on a Merkle tree, has been developed to ensure continuous data integrity of users’ transactions by periodically com-puting and publishing a root hash. It uses a Merkle hash tree to hash and timestamp the users’ transactions. The security of this technology does not deploy keys during the root hash generation. Hence, data authentic-ity and non-repudiation cannot be offered. Rather, this technology provides a proof of existence of any content that is hashed by a given node at a certain time. In fact, each root hash will be timestamped to prove that certain data was created at a specific time. The root hashes are linked timestamping, making backdating of the issued timestamped root hashes impossible without tampering the whole structure. Timestamp linking offers a verifiable and ordered link between the current and already issued timestamped root hashes. in other words, the current time-stamped root hash will prolong the proof of existence and integrity of previous time-stamped root hashes. Periodic publication of root hashes in widely witnessed media such as newspapers or a blockchain enhances transparency and protection against any mod-ification in the hashed content, and provides a proof of existence of a certain content. While the hash functions are used to reduce the integrity verification of large documents to integrity verification of short bit strings
3. Related works Several previous works have addressed the issue of multi-party nonrepudiation by using different tech-niques such as PKI-based solutions (Cooper et al., 2008), electronic notary (Lan, Xinping, Hanchun, & Jiancheng, 2016), trusted third party (TTP) (Caifen et al., 2002), IDbased non-repudiation (Kannisto et al., 2015), and so on. The authors in (Vigil et al., 2015) identified and analysis three types of solutions to provide long-time integrity protection and non-repudiation: timestamping-based, notarization-based and replication-based solu-tions. In this paper, we focus on the time-stamping-based solutions discussed in (Vigil et al., 2015), which are used to verify that a document existed at some point in time and to ensure the document’s integrity since its publication time. For more discussion on the advantages and drawbacks of these solutions, please refer to (Vigil et al., 2015). In Onieva, Zhou, and Lopez (2008), the authors describe the general multiparty non-repudiation problem, and discuss two main architectural categories: 1-n and n–n (where n is the number of participating parties). Recently in Kilin and Kp (2015), the authors describe a solution that requires O(n2) messages and a constant number of rounds. They demonstrate a superiority of their proposed solution in comparison to many existing solutions. As described later, our proposed solution requires O(n) messages. Moreover, our solution is based on the use of hash functions which are by far faster than the signature algorithms. Merkle tree by its sign does not provide neither authentication nor non-repudiation of origin/receipt. In parallel, most of the existing crypto-based solutions assume that there is no sudden break of cryptography. However, we have experienced attacks that can defeat some encryption cryptosystems such as RSA (Kleinjung et al., 2010). In the following section, we present our solution to combine Merkle trees and secret keys to provide continuous data integrity and non-repudiation for multiple entities. To the best of our knowledge, this is the first work of its kind available in literature. The authors in Jamthagen and Hell (2016) discuss some limitations related to the Merkle hash trees, particularly to the publication of root hashes in widely witnessed media to ensure continuous data integrity. They describe a publication layer based on the use of blockchain to publish the root hashes so they can be accessed by anyone and verified anytime. However, this approach inherits the blockchain limitations in terms of transaction fees, continuous stor-age increase, and of the
Fig. 1. Example of a hash tree with 4 leaves (depth = 2). 190
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
by e during a past round). Otherwise, the key k[e,i] should not be trusted by the third party.
security concerns described in Jamthagen and Hell (2016). The authors in Emmadi and Narumanchi (2017) describe an approach to ensure irreversibility and irrefutability of transactions already published in the blockchain. They propose using KSI as a complement to the blockchain to ensure the blockchain’s integrity without even monitoring it. In Vigil et al. (2015), the authors describe the use of a time-stamp authority (TSA) to issue signatures that are time-stamped as follows: each entity hashes its document and sends the result to the TSA, which creates a time-stamp and then signs the concatena-tion of the time-stamp and the hashed content it received from the entity, before transmitting the signature back to the entity. In our approach, the root hash is transmitted to every leaf in the tree and hence, the continuous data integrity is proved by means of a majority vote (i.e., replication) (Vigil et al., 2015) and of individual secret keys divulgated by each entity involved in the generation of the root hashes and verified by the receivers of the root hashes.
Since there is a finite number of secret keys that could be generated by each entity e at a given time, it may be possible for e to deploy all its keys when reaching a certain round r = ne − 1, during which the key k[e,1] is used by e. Now, e repeats the process described in the previous Section to generate a new individual secret key k[′e,0] , a new key vector V[′e, k] and a new synchronization vector Ve′. Both vectors are of a new size ne′. Then, e applies the hash function on both the keys k[e,0] and k ′[e, ne′] (e.g., H (k[e,0], k ′[e, ne′] ) ) and replaces k[e,0] with k[′e,0] . During the following round (i.e., r = ne), e divulgates k[e,0] so every third party can verify H (k[e,0], k ′[e, ne′] ) and then trust the new generated key k ′[e, ne′] when this latter is divulgated by e during the subsequent round.
4. Proposed solution
4.4. Lifecycle of the rounds’ references
In this section, we present our proposed solution to provide longterm integrity and non-repudiation for multiple entities. The proposed solution is based on forming a Merkle tree where the leaves are entities willing to sign a sequence of documents using individual secret keys. In the rest of this paper, we assume that each secret key is used for one time only. This can be verified by any third party during any round, as described later.
The number of rounds is encoded using a limited number of bytes (for example 2-bytes length or 216 rounds), leading to reset the roun’s counter to 1 and resulting in using the same counter for different rounds. However, this is not an issue since the root hashes are timestamped and it will be obvious to distinguish between the hashed contents generated by a certain entity by jointly using the time-stamps and the round reference. It is worth noting that, during a certain round r, it may be possible that some entities have contents to hash and some others have not. In this case, each entity having a content to hash will use the key that is corresponding to the round’s reference (e.g., r). Upon receipt of the root hash from the server, every entity will update the round reference and properly map between it and the reference of its last undisclosed key.
4.3. Key updating
4.1. Abbreviations and acronyms Table 1 summarizes the notations used in this paper. 4.2. Key initialization phase During an initial phase, each entity e (i.e., the server s and the tree’s leaves) generates an individual secret key k[e,0] that should never be divulgated to any third party, and generates a key vector, which consists of a certain number ne of individual secret keys, as follows:
V[e, k] = (k[e, ne − 1] ), k[e, ne − 2], …, k[e,1], k[e,0] )
(1)
k[e, i] = H (k[e, i − 1] ), 1 ≤ i ≤ n
(2)
4.5. Key revocation It is always possible for an attacker to compromise a device that contains the undisclosed keys. Our solution allows each compromised entity e to revoke its undis-closed keys or a subset of these key, so the attacker can neither pretend to be the entity nor send hashed content on its behalf. When e detects a key compromise at some point in time (i.e., between rounds r and r + 1), it will disclose both its last undisclosed key and its initial key k[e,0]. Any third party, including the server, will apply Eq. (2) to first verify that the key used by e during the previous round (i.e., k[e, ne − r ]) is generated from the key (i.e., k[e, ne − (r + 1)]) disclosed by e after it has been compromised, and that both the two keys are generated from k[e,0]. Next, the server revokes the undisclosed keys of e, and either updates the tree by removing e from the tree or validates the new key k[e, ne′] generated by e. It is worth nothing that the server will be able to confirm that k[e, ne − (r + 1)] is generated from k[e,0] by recursively applying Eq. (2) on this latter for (ne − r − 1) times.
Each entity e maintains a synchronization vector Ve = (1, 2,..ne). Each element in Vx is used as a reference to a generated secret key (i.e.,k[e,i] has the reference (ne − i + 1) that is corresponding to the round i). It is worth noting that a time-based reference could be used instead of the synchronization vectors, but this requires every entity to have an internal clock and more communication overhead to synchronize and validate the current time between the involved entities. When a third party receives, during the round i, a hashed content that is generated by e using the key k[e,i], it would verify that k[e,i] is generated from k[e,j] by applying Eq. (2) on k[e, j] (i.e., k[e,j] is divulgated
4.6. Root hash generation and publication
Table 1 Notations and definitions. Notation
Definition
e
Entity (server and users) The key vector of the entity e The synchronization vector of e The number of keys generated by e The key used by e during the round r Hash Function A root hash published by the server at round r A root hash generated by a root node at round r Concatenation Depth of the tree The length (bytes) of the hashed content using H
V
[e,k] V [e] n [e] k [e,r] H root_cal[r] root hash[r] ∣ d H.size
During each round r, the server s hashes, using its secret key k[s,r], the concatenation of the current root hash and the las root hash rooth _cal[r−1] previously published by the server (e.g., in a hash calendar), as follows:
roothcal[r ] = H (roothcal[r − 1] ) root hash[r ], k[s, r ] )
(3)
Next, the server divulgates its secret key k[s,r], so each entity will be able to: a) verify the existence of its hashed content by regenerating the roothash[r] using the authentication path it receives from its parent node, and b) check the integrity and the authenticity of the root_cal[r]. Then, each entity e divulgates its secret key k[e,re] that is linked to the round r and used to generate the hashed content of e. 191
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
Fig. 2. Example of the proof of existence of hashed content.
server the last key it generates. Any other key generated by e during this phase is unknown to any third party, including the server. The keys generated by e are linked one to the other (Eq. (2)) and the first key divulgated by e is the last key it generated. Hence, when e divulgates a key during a given round r, the server will apply Eq. (2) on the previous key divulgated by e to verify whatever it is derived from the key disclosed during the round r or not, and then to authenticate e and its hashed content transmitted to the server. It may be possible for an adversary to reuse a key that is already divulgated by e during a past round to inject false data. However, the server and any third party will be able to detect the adversary action because 1) any key should not be used more than one time, and 2) the hash of the key used by the adversary will not be equal to the hash of the last key divulgated by e. During a certain round r, only the entity e knows the key that is mapped to r (e.g., k[e,r]) and any other entity knows the key that is corresponding to k[e,r] (i.e., k[e,r−1]). Hence, during the round r, only e can generate a valid hashed content using k[e,r]. This is equivalent to the case when e signs a document using a digital certificate, in which the private key used to sign the document is not shared with any third party; only the public key corresponding to the private key is publicly available, so any third party can validate the signature using that public key. In our solution, everyone will be able to validate the hashed content once the key used by e during the round r is divulgated. After receiving the root_cal[r] from the server, the entity e cannot deny that it didn’t use k[e,r] to generate its hashed content and therefore, the nonrepudiation of origin is guaranteed. Our solution offers the non-repudiation of receipt as well. In fact, during the same round, the server s will generate rooth_ cal[r] using its last undisclosed key. Once this key is divulgated by the server, every entity will be able to verify rooth_cal[r]. As indicated Vigil et al. (2015), the expected lifetime of a hash function is usually longer than the expected lifetime of a signature algorithm. However, the security of hash functions is not everlasting. Choosing the appropriate hash function will depend on predicting the lifetime of that hash function. Generally, keyed-hash function is harder to break than a hash function (e.g., the case of HMAC-MD5 and MD5). Since our approach is based on the use of keyed-hash function, it is assumed to predict the lifetime of the keyed-hash function once the hash function itself is suddenly compromised, and then to replace the hash function with a more secured one. In contrast to the distribution of the hashes of both the authentication path and the root node, we leverage the benefits of the replication approach, which provides long-term integrity of document without
4.7. G. Proof of existence of hashed contents and of the root hash As previously indicated, each entity e generates its hashed content by applying a hash function on both its content and its secret key (e.g., he = H(content, k[e,i])). The hashed content is then transmitted to the entity’s parent node. Each of the intermediate nodes in the tree will hash the concatenation of the hashed contents it receives from its child nodes and transmits the result to its parent node, until reaching the root node, which then generates the root hash (see Fig. 2, phase 1). The server generates the root_cal[r] by applying Eq. (3) on both the root hash and the key linked to the current round. Next, the server sends root_cal[r] back to its child nodes, along with its key k[s,r]. Each intermediate node in the tree from the top down until reaching the leaves will forward any content it receives from its parent node to each of its two child nodes. In parallel, each intermediate node will send to its left (resp. right) child node the hashed content it previously received from its right (resp. left) child node. This will help in building the authentication path that is needed by each entity to validate the root_cal[r]. At this stage, each entity e generates the root hash by using the hashed contents of its authentication path and compares the generated root hash to the received roothash[r] for equality. If they are equal, then e will verify root_cal[r] by applying Eq. (3) on both k[s,r] and the concatenation of roothash[r] and the root hash it received during the previous round. If root_cal[r] is successfully verified, then e authenticates the server and accepts root_cal[r] as an evidence of existence for its hashed content. Now, e divulgates its key k[e,i] by transmitting it along with its hashed content to the server s (see Fig. 2, phase 3). Upon receipt, the server validates the hashed content of e using k[e,i]. 5. Security and performance analysis of the proposed solution In this section, we present a security and performance analysis of our proposed solution and we demonstrate its effectiveness in providing long-term integrity protection and non-repudiation of origin and of receipt as well. Moreover, we show that our solution is resilient to a wide range of attacks such as false data injection attacks and passive attacks. One of the attacks against data integrity if False Data Injection (FDI), in which the attackers intentionally change the data in a way that the receiver will be unable to detect forged or malformed data when collecting data from the origin. During the key initialization phase, each entity e shares with the 192
Sustainable Cities and Society 40 (2018) 189–193
M. Badra, R. Borghol
6. Conclusion
Table 2 Transmission and message overhead. Transmission
3*(2d+1 − 1)
Transmission (Optimized) Message overhead per entity
3*2d (d + 1)* H.size
In the context of smart cities, services are usually dis-tributed and their functionality is provided as the result of the interactions among several entities that are usually distributed across several computing devices. In this paper, we presented a long-term data integrity and nonrepudiation solution for multiples entities. Our scheme makes use of a Merkle tree and of sequences of secret keys to generate a time-stamped hashes that are authen-ticated and integrity protected. Moreover, our solution offers a continuous proof of existence of contents. We have demonstrated that our solution is efficient in terms of crypto-computational and communication overheads, and is designed to be more resilient to various attacks, including data forgery and data injection attacks. Finally, we argue that our proposed solution design is appropriate when resource-constrained devices are involved. As part of our future work, we will develop and test our proposed approach with different settings to validate its effective-ness and the accuracy of results it gives. Moreover, we will extend it to meet the requirements of multi-party contract signing architectures.
using cryptog-raphy and without using widely witnessed media such as newspapers or a blockchain. We used the following performance evaluation metrics in our performance analysis: 1) Transmission Overhead: this is the number of transmissions between the entities. 2) Message Overhead: this is the memory space used by an entity for storing information about a content, and the percentage overhead of different components (content, crypto-operations) in each operation. When all the leaves of a tree are at same depth d, the tree will contain N = 2d leaves. This is the maximum number of leaves of a binary tree of depth d. As for the authentication path that is needed to verify a root hash by each entity, it cannot exceed log2(N) = d hashes. In other words, the number of hashed values that should be stored by each leave during a certain round is d hashed contents. If we assume that the intermediate nodes are running on the server or on a dedicated host, then the number of transmissions required to generate a root hash is only 2d. A similar number will be needed to send the root hash, the server’s key and the authentication path to each leave in the tree. In addition, one transmission is needed by each entity when divulgating its key. Hence, a total of 3 *2d transactions are needed per each round. Table 2 summarizes the transmission and the message overheads per each round. We theoretically compare between our proposed solu-tion and the traditional PKI-based solutions in terms of performance efficiency and security features. In a PKI-based solution, each party needs to have a digital certifi-cate, verify each certificate in the certificate chain, and to consult the CRL as described above. The sender then signs its document using its private key, and the receiver will decrypt the sender’s signature using the sender’s public key, compute its hash on the received document, and then compare the two hashes for equality. Next, the receiver will sign a time-stamped hash of the received document and send it back to the sender, in which the sender will follow the same steps as the receiver to verify the receiver signature. In our approach, each entity will hash its document and verify (log2(N) + 1) hashes, which are the hashes generated by the entities in its authentication path. Each intermediate node in the tree will compute one hash. The server will verify d hashes and generate only one. During the key verification process, each entity will verify the key disclosed by the server by applying one hash (Eq. (2)), and the server will generate d hashes. Finally, the server will generate one hash when publishing the root hash in the hash calendar.
References Buldas, A., Kroonmaa, A., & Laanoja, R. (2013). Keyless signatures infras-tructure: How to build global distributed hashtrees. In H. Riis Nielson, & D. Gollmann (Eds.). NordSec 2013 (pp. 313–320). LNCS 8208. Caifen, W., Jianhua, G., Xinjun, D., Jin, Q., Tieshan, Z., & Shiyong, Y. (2002). A multiparty non-repudiation protocol with semi-trusted third party. Proc IEEE region 10 conference on computers, com-munications control and power engineering, 188–191. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., & Polk, W. (2008). Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile. IETF RFC 5280. Emmadi, N., & Narumanchi, H. (2017). Reinforcing immutability of per-missioned blockchains with keyless signatures’ infrastructure. Proc ICDCN. Jakobsson, M., Leighton, T., Micali, S., & Szydlo, M. (2003). Fractal Merkle tree representation and traversal. Cryptographer’s track at RSA conference, 314–326. Jamthagen, C., & Hell, M. (2016). Blockchain-based publishing layer for the keyless signing infrastructure. Proc IEEE conferences on ubiquitous intelligence and computing, advanced and trusted computing, scalable computing and communications, cloud and big data computing, internet of people and smart world congress, 374–381. Kannisto, J., Takahashi, T., Harju, J., Heikkinen, S., Helenius, M., Matsuo, S., et al. (2015). A non-repudiable negotiation protocol for security service level agreements. Int. J. Communication Systems, 28(15), 2067–2208. Kent, S., & Seo, K. (2005). Security architecture for the internet protocol. IETF RFC 4301. Kilin, H., & Kp, A. (2015). Optimally efficient multi-party fair exchange and fair secure multi-party computation. Proc CT-RSA, 330–349. Kleinjung, T., Aoki, K., Franke, J., Lenstra, A. K., Thome, E., Bos, J. W., et al. (2010). Factorization of a 768-bit RSA modulus. Proc CRYPTO, 333–350. Lan, L., Xinping, H., Hanchun, C., & Jiancheng, D. (2016). Non-repudiation scheme of smart home based on cloud service. Proc sixth international conference on instrumentation and measurement, computer communication and control, 453–456. Merkle, R. C. (1987). A digital signature based on conventional encryp-tion function. Proc CRYPTO. Springer Verlag. Onieva, J., Zhou, J., & Lopez, J. (2008). Multi-party non-repudiation: A survey. ACM Computing Surveys, 41(1), 1–49. Rescorla, E. (2017). The transport layer security (TLS) protocol ver-sion 1.3. IETF Proposed Standard. Vigil, G., Buchmann, J., Cabarcas, D., Weinert, C., & Wiesmaier, A. (2015). Integrity, authenticity, non-repudiation, and proof of existence for long-term archiving: A survey. Computers and Security, 50, 16–32.
193