nueva página del texto (beta)
Inglés (pdf)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introduction
Today, cryptographic hash functions constitute a main component of a variety of authentication protocols to achieve data integrity and non-repudiation services. Hash cryptography has been implemented throughout a variety of algorithms which include the Message Digest Algorithm (MD5 (Rivest, 1992)), the Secure Hash Algorithm SHA-1(Eastlake 3rd and Jones, 2001), SHA-2 (P. U. B. FIPS, 2002) and SHA-3 (DRAFT, 2014). One of the major advantages of hash cryptography is that it is not based on modular mathematics, so it does not require large prime computations and it is suitable for small mobile computing devices. Hash cryptography is resistant to quantum-crypto-analysis (Perlner and Cooper, 2009), which is not the case of modular arithmetic that is based on the Integer Factoring or the Discrete Logarithm Problem (Nielsen and Chuang, 2010; Dattani and Bryans, 2014; Dridi and Alghassi, 2016) due to Shor’s factoring algorithm for quantum computation (Shor, 1994). Moreover, special purpose devices run hash chains in the order of 300 peta hashes per second (Zohar, 2015). Hash based signatures run at least 104 faster than modular-arithmetic based methods (Muñoz et al., 2004).
Since Leslie Lamport introduced hash chains (Lamport, 1979; Lamport, 1981c; Hu et al., 2005), some technologies implement this algorithm as the S/Key One Time Password (OTP) (Haller, 1995) but few attempts have been made to get authentication protocols based on hash chains (Perrig et al., 2005; Anderson et al., 1998). Other protocols have been developed under hash functionality as Time-based One-Time Password (RFC (M’Raihi et al., 2011)) or HMAC-based One-Time Password (RFC (M’Raihi et al.,2005)).
An attempt to achieve a public key cryptosystem by means of hash cryptography is the One Time Signature (OTS) method developed by Leslie Lamport (1979). However, in this protocol the message signature process can be executed only once. OTS can be optimized through some methods (Merkle, 1982; 1987; 1989; Buchmann et al., 2009). Using a Merkle tree, it is possible to increase the number of messages that can be signed, however one pair of public/private OTS key must be generated by each leaf and they must be stored in the user end device for future message signing.
On the other side, modular-arithmetic signature schemes include the Digital Signature Algorithm proposed by the US National Institute of Standards and Technology (NIST) (N. FIPS, 1998; Fips, 2000; P. U. B. FIPS, 2009), the RSA algorithm (Rivest et al., 1978) and the Probabilistic Signature Scheme which is part of the standard (P. U. B. FIPS, 2009) and the Elliptic Curve Digital Signature Algorithm (ECDSA) (Triwinarko, 2006) which is also included in (P.U.B. FIPS, 2009).
Such algorithms are based on modular arithmetic computations, which requires in some cases large prime numbers and in other cases modular multiplication and/or exponentiation. Moreover, the generation and preparation of the pair of public/private key is computationally costly. In contrast, hash technology is advantageous for potential use in mobile and low-performance hardware devices.
Since there is no quantum algorithm to efficiently analyze hash functions (Perlner and Cooper, 2009), it is assumed that cryptography based on hash functions, as Merkle trees, are post-quantum (Merkle, 1982; Buchmann, 2016). However, for exhaustive search, Grover's quantum algorithm reduce the search space approximately to
According to (Buchmann et al., 2016) “there are no hash-based public-key encryption schemes.” However, multivariate signature schemes exploit hash functions to get its advantages. As a result, multivariate cryptography produce signatures speedily and the verification process is time reduced. Moreover the signatures are shorter than RSA. Unfortunately, the key sizes of signatures are still relatively large (Buchmann et al., 2016).
In this work we will introduce a signature scheme based just on hash functions where the key sizes varies from 256 to 512 bits. The method is the first known for public key infrastructure based just on hash functions and it can be used to achieve Digital Signature services. Moreover, it allows the Certification Authority functionality.
We should remark that hash cryptography is resistant to quantum-crypto-analysis (Perlner and Cooper, 2009), which is not the case of modular arithmetic that is based on the Integer Factoring or the Discrete Logarithm Problem (Nielsen and Chuang, 2010; Dattani and Bryans, 2014; Dridi and Alghassi, 2016) due to Shor’s factoring algorithm for quantum computation (Shor, 1994).
The hash signature algorithm
In this section, we will detail our proposal called the hash chained signature protocol. However, let us introduce some previous concepts of hash functions and hash chains.
Hash function
A hash function takes as input a message which is a string of bits of arbitrary length, and it produces as an output a string of bits of fixed length determined by the hash function. The output is called hash code. The hash function is expressed as h=f(X) where X corresponds to the input or message (Nigel, 2016).
Hash functions are characterized by two main properties:
From the computational point of view, it is infeasible to get the message X if known h.
It is infeasible to find two different messages with the same hash value.
On the other hand, a hash chain is a sequence of values derived consecutively from a hash function from an initial value (Figure 1). Due to the properties of the hash function, it is relatively easy to calculate successively chained values (Dwight, 2011).
The hash chained signature protocol
In our protocol, Alice wants to sign a message and send it to Bob. Alice and Bob must execute the next steps:
Alice and Bob generate their pair of public-private keys.
They exchange their public keys through the public channel.
Alice signs a message using her private key.
Bob verifies the signature using Alice’s public key.
To generate the keys the following cryptographic functions are necessary:
To produce the keys Alice (or Bob) generates a small random number (e.g. 128, 160, 256, 512 bits length). We call this number the sieve
Table 1 The keys of the Hash Chained Signature protocol, here
| User | Public Key | Private Key |
|---|---|---|
| Alice |
|
|
| Bob |
|
|
To sign a message, it will be used the Hash Message Authentication Code (HMAC) function (Krawczyk et al., 1997). Suppose Alice wants to sign a message and send it to Bob, then Alice and Bob perform the following steps:
Using a public channel, Alice and Bob exchange their public keys f NA
Applying the HMAC function, Alice signs the message
Bob sends his private key
Only in the case that authentication is verified successfully Alice sends to Bob the message
Finally, Bob performs the HMAC computation of the message denoted as
Table 2 depicts the protocol where the
Up to our knowledge, this is the first protocol that uses hash chains for signing message with a private key. The private key consists of a chain of private keys of short duration. The seed used to compute the chain, as well as the private keys remain secret until the key is used for a transaction. In such a case, the private key is no more secret and becomes public. This process continues until the chain of keys is renewed.
Unlike conventional public key schemes, here the public and private keys change at each transaction. That is, the private key is substituted each time. This is needed in order to authenticate the user, whose private key is validated by applying the hash function to the key, the result must be the public key.
The protocol is interactive and gives mutual authentication between Alice and Bob. So, it is useful for one-to-one communication because the destination authenticates the signed message.
It is dynamic because every time a private key is revealed it becomes part of the public key. So, verification of th/e public key can be achieved using the current public key or any key in the public hash chain.
Security analysis
However, Alice and Bob do not have a way to verify the authentication keys,
Table 3 MITM attack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Despite the MITM attack described before, the basic Hash Chained Signature protocol is still usable for dedicated point-to-point links where as stated before, each new key can be verified from the previous one, e.g.
Certification authority
To surpass such MITM attack we will introduce the Certification Authority (CA) to the protocol. But before discussing the CA, we must mention two protocols that share some similarities with the hash signature system:
The Delayed Authentication Message (DEMA) Protocol presented in (Groza, 2006) is in fact equivalent to the Hash Chained Signature protocol discussed here. However, DEMA protocol is aimed for point to point synchronized connections. In contrast, we preserve the basic structure of the protocol but we achieve signature services through the Certification Authority.
In (Buldas et al., 2014b) is described a signature scheme, in which the client computes a Merkle tree constructed with a hash chain. From the Merkle tree the user generates his public key. In addition, the client emits a time stamp to the signature server to determine the interval the certificate will be valid. The server generates a hash tree from the time stamp to be used with the client. In this scheme, the authors identify a problem: many keys are not used because they are only valid for a certain period of time. In (Buldas et al., 2014a) they propose a new scheme where the main idea is to use the signature message as a public key revocation. The message includes the period that the key will be valid. Another difference is that the client must store all the created signatures in case of later disputes.
The Certification Authority (CA) will be responsible to maintain the Hash Chained Signature system, registering new users and exchanging signatures. It must be remarked that the CA does not store the secret keys of users, as typically achieved with a Key Distribution Center (KDC). By contrary, each private key is kept by its owner and never leaves the user side. The CA just act forwarding the message signatures between users. For this purpose, the CA prepares a public key to communicate with each user, for example in the case of Alice the CA generates the public key
Table 5 Alice (or Bob) and the CA maintain an ordered public key exchange
|
|
|
|
|
|
|
|
|
In this way, the CA acts as a gateway between Alice and Bob to exchange their signatures each time they communicate. To guarantee non-repudiation Alice sends the hash of the message she wants to sign. The CA performs message accounting by storing message signatures (she does not store messages themselves). The complete protocol has been specified in Table 6. We have included an authentication key of the user,
Table 6 Signature exchange where
| A → CA: |
|
| AC → B: |
|
| AC ← B: |
|
| A ← CA: |
|
| A → CA: |
|
| AC → B: |
|
| A → B: | m |
The CA does not have access to private keys of the users, however she must be in the middle each time a pair of users want to communicate securely. Therefore, the computational cost of the CA process would be a concern for this protocol. However, it is common that e-transactions in Internet based protocols are verified by a Third Trusted Party (3TP).
The next step is to develop a method to efficiently manage the keys of the users. We discuss this question in the following section.
Merkle tree chain
The CA must prepare a public key to communicate with each user. To accomplish this task the CA implements a Merkle Tree (Merkle, 1982) whose leafs are deserved to allocate the pairs of public keys between the CA and each user. The Merkle Tree will be publicly announced and the CA identity will be verified through the computation of the root of the tree.
To validate the identity of the CA each user will receive the required Hash nodes to compute the Hash root. However, a pair of leaves of the Merkle Tree will not be used neither revealed, instead of that they will be kept secret so that the last leaf will be deserved to bind the current tree with the next tree of the tree chain. Therefore, a pair of leaves of each new tree that is concatenated to the tree chain is kept secret, Figure 1 shows this concept.
In the example of Figure 2, the
As time goes, multiple trees are created and the CA stops creating new trees but she proceeds to assign the unused leaves. For this task, the CA enumerates again the unused leaves and the algorithm is executed again. A higher order level can be appended to the tree merging the roots H 1,11 and H 2,11 into a new root, such that the Merkle tree algorithm keeps running efficiently.
Renewing the certificate
To update her public key Alice computes a new pair of public/private keys and she signs the new public key with an older private key. Then, the CA advertises the key update. Since the new key is signed by Alice and it is published by the CA the renewing process does not compromises the security of the protocol. The steps of the process are represented in Table 7.
Multiple CA’s
Multiple CA’s can contribute to decrease the computational effort of a single CA. To allow interoperability between multiple CA’s each CA must register with the other CA, this process is represented in Table 8. Suppose for example, that
Table 8 Alice wants to send a signed message to Bob but Alice is registered with
| ,A → CA 1 : |
|
| CA 1 → CA 2 : |
|
| AC 2 → B: |
|
| B →AC 2 : |
|
| CA 2 → CA 1 : |
|
| CA 1 → A: |
|
| A → CA 1 : |
|
| CA 1 → CA 2 : |
|
| CA 2 → B: |
|
| A → B: | m |
Table 8 shows the protocol when users are registered to different CA’s. This scheme can be generalized to multiple CA’s. However, we leave for an ulterior work the implementation of multiple CA’s and the analysis of interoperability with multiple domains.
Experimental results
In this section, we describe the results obtained with the Hash Signature system applying different sizes of the message. The CA was developed on NetBeans 8.1 in a computer desktop equipped with Pentium Dual-Core, 4 GB RAM. The client application was built over Android Studio 2.3. Tests were performed on two different mobile phones. They are detailed in Table 9.
Table 9 Mobile devices used to perform tests
| Device | Model | CPU | Android version | Internal GB memory |
|---|---|---|---|---|
| Samsung | GT I8190 | 1 GHz dual core ARM Cortex-A9 | 4.1.2 Jelly Bean Fou | 8 |
| Samsung | SM G920I | 2.1 GHz, 1.5 GHz Octa-Core | 6.0.1 Marshmallow | 32 |
We generated 1024-leaf trees in 5 milliseconds. In the first test we used the same string as it was used in (Alese et al., 2012): "ECDLP is believed to be harder than both the Integer Factorization and Discrete logarithm Problems". After 10 tests, we take the average of the elapsed interval. To make comparisons we take the encryption process as the signature generation (Alese et al., 2012). The size of the key, in the mobile device and the AC, is the corresponding to SHA-2 (256 bits).
The key generation interval was computed taking the time to get the random seed
Table 10 Results of the SHA-256 hash signature are compared with respect to Alese et al. (2012), values are represented in millisecond
| Size of Key (bits) | Key Generation (ms) | Signature Generation (ms) | Signature Verification (ms) |
|---|---|---|---|
| RSA 1024 | 1312.7±190.8 | 166.9±46.3 | 15.7±0.4 |
| RSA 2048 | 6804.6±2540.6 | 290.2±29.8 | 122.4±9.1 |
| RSA 3072 | 32180.0±18947.7 | 310.5±75.5 | 293.2±71.8 |
| RSA 7680 | 322843.0±233809.0 | 352.1±154.1 | 2932.8±44.7 |
| RSA 15360 | N/A | N/A | N/A |
| ECC P-160 | 198.6±12.5 | 17.9±4.9 | 15.7±0.1 |
| ECC P-224 | 208.3±13.4 | 95.9±6.8 | 18.7±5.5 |
| ECC P256 | 243.5±22.2 | 35.1±6.1 | 21.1±6.8 |
| ECC P384 | 294.0±26.5 | 74.9±7.1 | 47.7±3.2 |
| ECC P-521 | 447.8±90.9 | 138.2±4.9 | 109.9±0.3 |
| SHA-256 hash signature | 240.25 | 39.21 | 12.5 |
Table 11 The processes of signature generation (SG) and signature verification (SV) are compared between the hash signature system (AC with SHA-256) and Mahto et al. (2016) taking an 8 / 256-bit message input (results are computed in milliseconds)
| 8 bits | 256 bits | |||
| Size of Key | SG (ms) | SV (ms) | SG (ms) | SV (ms) |
| RSA 1024 | 30.7 | 754.3 | 550 | 19310 |
| RSA 2048 | 29.9 | 2707.5 | 580 | 102030 |
| RSA 3072 | 30.5 | 6940.9 | 560 | 209600 |
| ECC 160 | 488.5 | 1326.7 | 7920 | 22880 |
| ECC 224 | 2203 | 1586.3 | 39700 | 26330 |
| ECC 256 | 3876.3 | 1769 | 58430 | 27400 |
| AC with SHA-256 | 32.7 | 18.5 | 39.87 | 17.8 |
Figure 3 The hash signature system SHA-256 is compared to Alese et al. (2012). These results show that the signature with SHA-256 is similar to ECC P256 (key and signature generation) but faster in signature verification. With respect to RSA our proposal is faster most of the times
If we compare the performance of the hash signature system on mobile devices with a 256-bit message we get the results shown in Table 12. Results are computed taking the average of twenty rounds. Although some parameters do not match (Tayoub et al., 2013) still are useful to compare the performance on mobile devices.
Table 12 The hash signature performance is compared against ECC (ECDSA) and RSA (results in milliseconds)
| ECC (ECDSA) (Tayoub, Walid; Somia, Lakehali; Chikouche, 2013) | ||||
|---|---|---|---|---|
| Device | Size key Operation (bits) | Generation key (ms) | Signature (ms) | Verification (ms) |
| GT-S6102 | 160 | 767 | 561 | 1285 |
| 224 521 | 615 | 699 | 1217 | |
| 595 | 562 | 141 | ||
| GT-I9100 | 160 | 303 | 412 | 681 |
| 224 521 | 443 | 360 | 624 | |
| 595 | 562 | 141 | ||
| RSA (Tayoub, Walid; Somia, Lakehali; Chikouche, 2013) | ||||
| GT-S6102 | 1024 | 1088.66 | 14.33 | 1 |
| 2048 15360 | 3896 | 77.66 | 1 | |
| >1h | \ | \ | ||
| GT-I9100 | 1024 | 1150 | 28 | 0.33 |
| 2048 15360 | 2341.66 | 95 | 1 | |
| >1h | \ | \ | ||
| Hash Signature system with SHA-256 | ||||
| GT-I8190 | 256 | 1678.47 | 566.75 | 468.91 |
| SM-G920I | 256 | 158.55 | 128.65 | 94.22 |
Figure 4 The hash signature system SHA-256 is compared to Tayoub et al. (2013). These results show that the hash signature system 256-bit, running in the SM-G9201 device is faster than ECC (ECDSA) 224-bit and RSA 1024-bit when comparing the time required for key generation, signature and verification
To guarantee the non-repudiation service, the CA maintains a log of the transactions between users. In Table 13 we show an example of an accounting record after an electronic transaction has been performed between Alice (A) and Bob (B) through the AC.
Table 13 The CA maintains registers of the transactions to provide accounting services. Here is an example:
| Username of Sender | Alice |
| Authenticity key of the issuer |
d9e3ac586c94e9f4fcbc3ebdc6bde5e9e059ffc569e78909d574a90d23981cc9 |
| HMAC of Message Hash |
b5500c57b24aff2e8f0a223a8db300760f7bbc7cb382ccb8c5c4dc5547a8c0a3 |
| Hash of Message |
b221d9dbb083a7f33428d7c2a3c3198ae925614d70210e28716ccaa7cd4ddb79 |
| Key for HMAC Sing |
0ff4d4bd8d0190b1579d57435abc4ba3c19f6b79b7e16017d586603d18aeae5b |
| Counter of Sender |
3 |
| Username of Receiver | Bob |
| Key of Receiver |
bacab276d9268c4d5c2d48ca8ce0bd3d8ad3b93be4b7370abe6f6b93f3ca7efd |
| Counter of Receiver |
2 |
The Android App that was developed for the hash signature system occupies 4.57 Mbytes. Figure 5 shows its interface. In general terms, we can describe the behavior of the system when Alice wants to sign a message m for Bob: Alice sends the signature code to the CA and she also sends a notification to Bob. He gets the validation code from the CA. Then, Alice shares him the message m (or file) through the Internet, e.g. a social network. Finally, Bob verifies the validation code along with the message m.
Discussion
Although we don’t have included a formal analysis about the security of the protocol, some points that enhance the security of the proposed protocol are: it is supported on the properties of hash functions that have been broadly discussed in the field. Despite this, we believe that a MITM could be tried by the attacker when users register with the AC. However, A MITM attack is limited by the following factors:
The MITM could attack two randomly users of the Merkle tree. Otherwise, the attacker must know the exact moment in which the users A and B will be registered before the AC, in order to attack the nodes.
Higher security certificates can be managed during the registration of users with the AC, which makes the attack more difficult.
To block the original message, the malicious entity would have to manipulate the application software through the message is sent, along the message service of the mobile phone or any application as social network. In this case, the attacker must create false messages and notifications.
The attacker would have to build a fake website of the CA, which would be detectable because the page is expected to be of public knowledge.
Conclusions
It has been discussed a method to achieve a Digital Signature protocol based on hash functions. When compared to ECC, experimental results on mobile devices demonstrate that the hash signature improve the efficiency to generate the keys and the signing and verification processes. At the same time, the hash signature is faster than RSA when generating 2048 keys. In addition, larger RSA keys consume much time while the hash system does not require to increase the size of the keys.
The hash signature system defines the Certification Authority to provide certification of users to guarantee the non-repudiation service. In such a case, the generation, sign and verification processes is faster than RSA and ECC.
The method discussed here which is supported by hash functions, belongs to post-quantum cryptography, and seems to be suitable for mobile network devices often limited in hardware capacities. Security of the method is highlighted because it is founded on the well-known security of hash cryptography.
