ePassport Problems reagrding MAC creation in ICAO 9303 "worked examples" in Java/Clojure

Question

i work on a application where I need to read Data from epassports. I'm working through the "worked examples" in ICAO Doc 9303 Part 3 Volume 2 (Third Edition).

There is a section in the worked examples, where they put together the MUTAUAL_AUTHENTICATE apdu. It involves calculating the MAC of "72C29C2371CC9BDB65B779B8E8D37B29ECC154AA56A8799FAE2F498F76ED92F2" with key "7962D9ECE03D1ACD4C76089DCE131543" which euqals "5F1448EEA8AD90A7". So with BouncyCastle I put together code that does the calculation so that it is inline with the document.

But then in the Section "Secure Messaging" the MAC of "887022120C06C2270CA4020C800000008709016375432908C044F68000000000" with key "F1CB1F1FB5ADF208806B89DC579DC1F8". This should equal "BF8B92D635FF24F8", but with the exact same Code that worked for the previous example i get a different result here. ("582AFC932A87F378")

How can that be? Do they change how MACs are createt in MUTAUAL_AUTHENTICATE and in Secure Messaging? I can't find anything in the document about it.

Here is my code, I'm using clojure, but all the work is done in BouncyCastle (Java)

(defn gen-mac [key message]
  (let [engine (org.bouncycastle.crypto.engines.DESEngine.)
        mac (org.bouncycastle.crypto.macs.ISO9797Alg3Mac. engine   (org.bouncycastle.crypto.paddings.ISO7816d4Padding.))
        bytes (byte-array (.getMacSize mac))
        key (->bytes key)
        msg (->bytes message)]
    (.init mac (org.bouncycastle.crypto.params.DESedeParameters. key))
    (.update mac msg 0 (count msg))
    (.doFinal mac bytes 0)))

That roughly translates to something like this in java:

mac = org.bouncycastle.crypto.macs.ISO9797Alg3Mac(org.bouncycastle.crypto.engines.DESEngine(), org.bouncycastle.crypto.paddings.ISO7816d4Padding());
mac.init(org.bouncycastle.crypto.params.DESedeParameters(key));
mac.update(msg, 0, msg.length);
mac.doFinal(bytes, 0)

edit: That's what the doc says:

f. Compute MAC of M:

i. Increment SSC with 1: SSC = ‘887022120C06C227’

ii. Concatenate SSC and M and add padding: N = ‘887022120C06C2270CA4020C800000008709016375432908C044F68000000000’

iii. Compute MAC over N with KSMAC: CC = ‘BF8B92D635FF24F8’

Also they provide a diagram, which doesn't make it clearer either. As pointed out below correctly. the key here is to compute the MAC over

N' = ‘887022120C06C2270CA4020C800000008709016375432908C044F6

I think their documentation ist really good, but at this point it's more then unclear. Would've never figured that out myself.

@sainaen: As a follow up, how did you managed to do that?

Answer 1

No, for the Secure Messaging they use the same algorithm, it's just that they don't pad data explicitly in the MuthualAuth example (because it's already of required length) and do that in the SM example.

Try to compute MAC with your code of "887022120C06C2270CA4020C800000008709016375432908C044F6" (which is a SSC + M without padding) and you'll get expected "BF8B92D635FF24F8".