ePassport Problems reagrding MAC creation in ICAO 9303 "worked examples" in Java/Clojure -
i work on application need read data epassports. i'm working through "worked examples" in icao doc 9303 part 3 volume 2 (third edition).
there section in worked examples, put mutaual_authenticate apdu. involves calculating mac of "72c29c2371cc9bdb65b779b8e8d37b29ecc154aa56a8799fae2f498f76ed92f2"
key "7962d9ece03d1acd4c76089dce131543"
euqals "5f1448eea8ad90a7"
. bouncycastle put code calculation inline document.
but in section "secure messaging" mac of "887022120c06c2270ca4020c800000008709016375432908c044f68000000000"
key "f1cb1f1fb5adf208806b89dc579dc1f8"
. should equal "bf8b92d635ff24f8"
, exact same code worked previous example different result here. ("582afc932a87f378"
)
how can be? change how macs createt in mutaual_authenticate , in secure messaging? can't find in document it.
here code, i'm using clojure, work 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 translates 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 doc says:
f. compute mac of m:
i. increment ssc 1: ssc = ‘887022120c06c227’
ii. concatenate ssc , m , add padding: n = ‘887022120c06c2270ca4020c800000008709016375432908c044f68000000000’
iii. compute mac on n ksmac: cc = ‘bf8b92d635ff24f8’
also provide diagram, doesn't make clearer either. pointed out below correctly. key here compute mac over
n' = ‘887022120c06c2270ca4020c800000008709016375432908c044f6
i think documentation ist good, @ point it's more unclear. would've never figured out myself.
@sainaen: follow up, how did managed that?
no, secure messaging use same algorithm, it's don't pad data explicitly in muthualauth example (because it's of required length) , in sm example.
try compute mac code of "887022120c06c2270ca4020c800000008709016375432908c044f6"
(which ssc + m without padding) , you'll expected "bf8b92d635ff24f8"
.
Comments
Post a Comment