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?


3 Answers 3


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.

  • unfortunately, this book doesn't explain "limit of the possibilities" too
    – osgx
    Jul 6, 2011 at 23:29
  • May be this is done to verify that MD-compliant padding is done in right way? Because if hash is not MD-padded, it is not so strong as should be.
    – osgx
    Jul 7, 2011 at 0:00
  • Thanks for your answer, but you're right - "somewhat limit the possibilities" is as good as claiming "it adds to the security" :) If the attacker knows the the protocol that is used between driver and card, then I see nothing that would prevent sending the correct parameters (padding, length...) for any forged data, too.
    – emboss
    Jul 7, 2011 at 0:38
  • 2
    there are some models, which needs last block hashing on the card, to protect the private key (protection from chosen ciphertext attack; if the last step of hash is in card, attacker can't easily choose texts). But if there is a mode of signing w/o hashing, this will not help. Last article have a lot of recomendations about security, so I recommend you read it fully.
    – osgx
    Jul 7, 2011 at 0:42
  • 2
    Skimming through your article I stepped over a comment that by using "Sign only" you could abuse the card as a "Deciphering oracle". I will have to wrap my head around this a little more in-depth but I am confident that this is what I was looking for. Thanks a lot!
    – emboss
    Jul 7, 2011 at 9:57

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, K1 and K2 (derivation uses only a simple XOR with conventional sequences, nothing fancy, the important point being that K1 and K2 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(K1 || h(K2 || 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 K1 or K2 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 K2 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 K2 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(K2 || m)) to the smart card.

  3. The smartcard then computes the second hash (the one which uses K1). There again, the hash function state achieved after processing K1 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.

  • 1
    Thanks for your answer! But I am really specific about digital signatures here - it is the notion of hashing the last block on the card before signing it that I'm particularly interested in.
    – emboss
    Jul 7, 2011 at 16:37
  • There are some rare HMAC/KMAC types which adds K after the messages, arent' they?
    – osgx
    Jul 7, 2011 at 21:18
  • 2
    @osgx: you can build a MAC out of a hash function in many ways, inputting the secret key at various places in the data stream, but it is easy to get it wrong (i.e. the construction is weak) because collision-resistant hash functions may still have some structure (and MD-based hash function do have exploitable structure). HMAC has been designed so that it is safe even when using a MD hash function such as SHA-256. In practice, HMAC is much more widely used than any other variant (except the HMAC-like construction used in SSL 3.0). Jul 8, 2011 at 12:24

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.

  • No, that was clear: the last round of hashing is performed on the card and immediately after that the hash is also signed on the card. The question is what the finalization of the hash calculation on the card adds to the general security of the process opposed to passing a completed hash to the card that is then to be signed directly.
    – emboss
    Jul 7, 2011 at 8:32
  • @emboss then I misinterpreted your question. osgx answered this aspect of your question, I think. I can add that some devices just don't have a "sign data" function (probably for security and performance reasons). Instead they offer only SignHash function. Jul 7, 2011 at 8:46
  • 1
    But both CWA and ISO require smart card to have both "Hash fully on card and sign", "Hash partially on card and sign" and "Sign".
    – osgx
    Jul 7, 2011 at 9:47
  • 2
    @osgx we see deviations from requirements here and there. I'd say that I have yet to see a device which has drivers completely compliant to standards (and free from standard violations). Jul 7, 2011 at 9:50
  • 1
    But do the standard deviants conform to a standard deviation?
    – this.josh
    Jul 7, 2011 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.