java - ePassport在ICAO 9303＆＃34;工作示例＆＃34;中重新考虑MAC创建的问题在JavaClojure中

我在一个应用程序上工作，我需要从epassports读取数据。 我正在通过＆＃34;工作的例子＆＃34;国际民航组织Doc 9303号文件第3卷第2卷（第三版）。

在工作示例中有一节，他们将MUTAUAL_AUTHENTICATE apdu放在一起。它涉及计算"72C29C2371CC9BDB65B779B8E8D37B29ECC154AA56A8799FAE2F498F76ED92F2"的MAC 使用euqals "7962D9ECE03D1ACD4C76089DCE131543"的密钥"5F1448EEA8AD90A7"。 因此，使用BouncyCastle，我将完成计算的代码放在一起，以便它与文档内联。

然后在第34节“安全消息传递＆＃34;密钥为"887022120C06C2270CA4020C800000008709016375432908C044F68000000000"的{​​{1}}的MAC。这应该等于"F1CB1F1FB5ADF208806B89DC579DC1F8"，但是使用与上一个示例相同的完全相同的代码，我在这里得到了不同的结果。 （"BF8B92D635FF24F8"）

怎么会这样？他们是否会改变MUTAUAL_AUTHENTICATE和Secure Messaging中MAC的创建方式？我无法在文档中找到有关它的任何内容。

这是我的代码，我使用的是clojure，但所有工作都是在BouncyCastle（Java）中完成的

"582AFC932A87F378"

在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)))

编辑： 这就是博士所说的：

  

F。计算M的MAC：

     

我。增加SSC 1：       SSC = '887022120C06C227'

     

II。连接SSC和M并添加填充：      N = '887022120C06C2270CA4020C800000008709016375432908C044F68000000000'

     

III。使用KSMAC计算MAC上的MAC：      CC ='BF8B92D635FF24F8'

他们也提供了一个图表，它也没有让它更清晰。 正如下面正确指出的那样。这里的关键是计算MAC

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)

我认为他们的文档确实很好，但在这一点上它还不清楚。我从来没有想过自己。

@sainaen：作为一个跟进，你是怎么做到的？

最佳答案：

1 个答案:

答案 0 :(得分：3)

不，对于Secure Messaging，他们使用相同的算法，只是他们没有在MuthualAuth示例中显式填充数据（因为它已经是必需的长度）并且在SM示例中这样做。

尝试使用代码"887022120C06C2270CA4020C800000008709016375432908C044F6"计算MAC（这是一个没有填充的SSC M），您将获得预期"BF8B92D635FF24F8"。