# Partial hash code protocol for security tokens providing signatures

I've read the following two sentences within a beta protocol specification, which references ISO/IEC 7816-8 for PSO:HASH which already contains notions of a "partial hash".

The off-card entity is responsible of computing the intermediate hash over the first part of the data to be signed. The intermediate hash-code is transferred to the token by the PSO:HASH command together with the remaining part of the data, the token performs the last round hash computation.

As far as I know, there is no standard that describes how a "partial hash-code" or "intermediate hash-code" values can be transferred. Does anybody know of a standard way to represent a partial hash code as octet string?

Note that in the protocol specification a "bit counter" is also send after the "intermediate hash-code", plus some last bytes of the message itself.

-
One link I found: community.oracle.com/thread/1751753 which mentions an APDU format. – CodesInChaos Aug 26 '14 at 12:13
@CodesInChaos That link just displays how to create the "data objects" that have to contain the intermediate hash value, not the intermediate hash value itself. The question is actually equal to that of mine. I've finally found out what is meant after following about 6 references. – Maarten Bodewes Aug 26 '14 at 17:28

## 1 Answer

The answer is in the CEN-EN 14890-1:2009, 7.3 General Aspects, and in the SHA-1 and SHA-2 specifications. The output of the hash algorithm for both SHA-1 and SHA-2 is the state of the hash algorithm (specified by $H^{(0..N)}_x$), after the last block is processed. So the output size is identical to the running state, possibly truncated to the leftmost bits.

The following calculations are for SHA-1 and SHA-224/256, for the other SHA-2 hash algorithms the block size is 128 bytes and the length encoding takes 16 bytes. To understand the calculations it is necessary to have read FIPS-180-4.

So first the message is split up into 64 byte message blocks, where the final block consists of 1 to 64 bytes. All the blocks are processed outside the token, up to - but not including - the last message block. The internal state and the amount of bits encoded so far is send to the token, together with the last bytes. Then one or two blocks of padded data - see 5.1 of FIPS 180-4 - have yet to be hashed by the card (expressed as a kind of regular expression on bytes represented as hexadecimals):

MM{r} 80 00{x} LL{8}


where $x = 53 - r$ for $r$ between $1$ and $53$ inclusive (one block) or $x = 117 - r$ for $r$ between $54$ and $64$ (two blocks) where $r$ is the amount of remaining bytes to be hashed.

Then the hash function calculates the final running state and truncates it to calculate the hash output, which in turn is used as input for signature generation.

-
As for now it is absolutely unclear to me why this is beneficial compared to just sending a calculated hash value. Nor is it clear to me what would happen if there is no obvious encoding into octets of the intermediate state of the hash function. – Maarten Bodewes Aug 26 '14 at 17:21
As for the first remark: I guess that the benefit to the (holder of the) security token is that it is guaranteed that only hash values are used as input to the rest of the signature scheme. – Maarten Bodewes Aug 27 '14 at 11:24