What is gained by hashing the last block on-device?

Question

Recently I encountered the notion of "hashing the last block on-device".

It means that when computing a digital signature, the hash that serves as input for the actual signature computation is not to be computed entirely in software but neither entirely in hardware - in fact the first n-1 blocks of the digest computation are computed in software for performance reasons and the final block is computed on the device (typically a smart card) before the final hash is used for the signature computation, again carried out on-device.

I was told that the smart card driver of the card we used at the time did exactly that when requested to produce a signature entirely on-device (hashing + computing the signature): The driver would compute the first n-1 blocks locally and then initialize the smart card with the current state of the digest, then send the remaining data for hash finalization and signature computation.

I was told that this would add to the security and at first I assumed that it was meant as a clever countermeasure against attackers that might intercept the hash computed in software, replace it by a hash of their own choice, thus obtaining a valid signature on data of their choice.

But the more I thought about it, the more it confused me. Nothing prevents attackers from pre-fabricating their hashes in the same way, i.e. compute n-1 steps of the digest calculation on the data of their choice and sending this to the device for finalization - again yielding a perfectly fine forged signature.

The only arguments I can think of why this might be preferred over computing the hash entirely in software are of legal nature. If the device and its algorithms are certified, then there is the guarantee that the input data for the signature computation has been provided by a certified implementation whereas there is no such guarantee if the hash had been computed entirely outside the device by a non-certified third-party software. I could imagine that this would affect legal discussions in case of a dispute over a particular signature.

Are there any real gains in security that I overlooked?

Answer 1

Citing from Smart card handbook By Wolfgang Rankl, Wolfgang Effing

The HASH option of the PERFORM SECURITY OPERATION command can be used to compute a hash value. The command may transfer either the data to be hashed or a hash value already computed outside the smart card along with the data needed for the final step of the computation. In the latter case, the hash computation for the final block is performed in the card. The advantage of the latter method is that the hash value can be generated significantly faster outside the card, but the final step still occurs inside the card. From a purely cryptological perspective, this provides only a small amount of extra security, but it does somewhat limit the possibilities for manipulating the hash value. For this reason, it is widely used in practice.

Last block of hash usually contains data length ("data needed for the final step").

This blog describes all modes of PERFORM SECURITY OPERATION:HASH command. They are: hashing everything on smart card; hash last part of data (he says nothing about length of this pard); don't hash anything, just do a signing.

This article says:

Let us point out that, for performance reasons, the hash function is generally performed outside the card. In particular, when the digital signature function is a keyed-MAC function, only the last block computation is performed on the card.

Answer 2

As stated, that policy is weird. For a true digital signature (as in RSA or ECDSA), the message to be signed is first hashed, and the rest of the operation uses the resulting hash value only. The hash computation uses only public elements; there is no key in the hash. Therefore, requiring part of the hash computation to be performed on the smartcard makes sense, security-wise, only if the smartcard may refrain from completing the signature based on what message data it gets: that is, if the smartcard could refuse the message because it does not end with a byte of value 0x5F, or any other similar arbitrary filtering rule. Such rules are pretty unusual in signing devices. Moreover, with a policy of "last block on the smartcard" and a usual hash function such as SHA-256, the smartcard only gets the last message bits (between 0 and 447 bits, depending on message length), and the total message length. That's not much for meaningful filtering rules. Without such improbable filters, requiring the last block of the message to be processed in the smartcard adds nothing at all to security.

Possibly, such a policy could be a devious fulfillment of strict legal requirements. For instance, some regulations could mandate that the hash "occurs in the smartcard" and might feel content with processing of the last block only. As an analogy, there was a time when European Union was enforcing strict quotas on car imports; a Japanese constructor then imagined to send cars without steering wheels, and also steering wheels, to a "factory" in England, where the almost-cars and the steering wheels were assembled. This was enough, according to European regulations, to make the cars "made in Europe", hence not subject to the quota.

However, there is an alternate scenario where the policy of "hashing the last block" on the smartcard makes much more sense. This is with HMAC. HMAC is for message authentication; it is not a "true" digital signature, but using the term "signature" to designate a MAC is widespread usage (though improper).

HMAC goes thus: from the secret key K are derived two block-sized values, K₁ and K₂ (derivation uses only a simple XOR with conventional sequences, nothing fancy, the important point being that K₁ and K₂ have the size of a hash function block, i.e. 64 bytes if the hash function is SHA-1 or SHA-256). Then, the MAC is computed of message m, using hash function h, as: h(K₁ || h(K₂ || m)).

So the bulk of the HMAC computation is basically a hash of the message m; but it must begin with the hash of a key-derived block, and there is an extra hash operation (again with another key-derived block) at the end. We do not want K₁ or K₂ to ever exit the smartcard (otherwise it makes little sense to use a smartcard at all). But a smartcard is not powerful (neither in CPU or I/O bandwidth) so we would prefer to perform most of the work on the external computer (in the smartcard driver). The HMAC computation would then go thus:

1. The driver informs the smartcard that a HMAC computation should take place; the smartcard processes K₂ through the hash function and returns to the driver the hash function state achieved at that point (this leaks no usable information on K because K₂ has the size of a block). Since this step does not depend on m, no real computation is needed here: the key-dependent state could have been computed once and for all when the smartcard obtained (generated) the key K in the first place.

2. The driver hashes m, starting with the hash function state obtained from the smartcard. The driver completes that hash computation (with padding) and sends the resulting value (which is h(K₂ || m)) to the smart card.

3. The smartcard then computes the second hash (the one which uses K₁). There again, the hash function state achieved after processing K₁ could have been precalculated, so the true online work consists in processing a single hash function block.

This scenario allows for fast, externalized computation, at the speed of the host computer, while keeping the secret key in the smartcard. My guess is that when a policy of "last block in the smartcard" is advertised, they really mean a HMAC computation as I just described. This entails sloppy terminology (a MAC is not a signature) but that's still better than EU-like bureaucratic absurdity.

Answer 3

I guess that it's hash signing operation that is performed on device on the last step, and then the scheme makes perfect sense: the last hashing operation is performed on the device and that computed hash is immediately signed using the private key which resides in the device (and which is not exportable). Otherwise, if only hashing is performed on the device, the scheme really doesn't sound reasonable.