Search code examples
securityencryptionsmartcardapduemv

EMV Secure Messaging


I am working on a project which requires Secure Messaging of an EMV card to protect data sent to/received from EMV cards.

According to the EMV Book 3, section 6.3.2: enter image description here

For my understanding, we can use 'Secure Messaging' on every command/response pair. For example, we can use CLA='8C', INS='CA' for Secure Messaging Format 1, and CLA='84', INS='CA' for Secure Messaging Format 2

However, when I tried on two of my cards I got error 6E 00 -- Class not supported.

What's wrong with my understanding about the 'Secure Messaging'?


Solution

  • None of the current EMV protocols seem to support secure messaging. Consequently, your card/EMV applet won't support secure messaging either.

    Also, I'm not quite sure what exactly you would want to use secure messaging for ... Excahnged information is already authenticated (under the assumption that you perform a transaction and that you do CDA/SDA/DDA). So you probably aim for encrypting the information exchanged between the terminal and the card (specifically things like the amount charged, static card data, etc.) However, I doubt that this would make much sense based on the design of the current EMV infrastructure:

    Terminals are currently not assumed to be trusted (at least with regard to the EMV protocol exchange between the terminal and the card). Consequently, you won't be able to implement any form of mutual authentication between the terminal and the card. Only the terminal could authenticate the card, the card could authenticate information received from the issuer (e.g. issuer scripts), but the card could never authenticate the terminal. As a result, impersonation of the terminal side would be possible despite encryption. Hence, an attacker in the middle would still be able to read and decrypt messages.


    From a comment by Michal Gluchowski:

    Maybe to extend what Michael has said, where next generation EMV is planning to go is to introduce channel confidentiality to eliminate passive eavesdropping. It will, however be possible to impersonate terminals (only card certificates will be authenticated). Current EMV uses secure messaging only for issuer scripts as it requires symmetric secret key that is known to issuer only. From the transaction perspective all the data terminal exchanges are plaintext (and issuer scripts are simply passed through without terminal analyzing or modifying them).

    Source regarding next generation EMV & channel security: Next Generation Kernel System Architecture Overview, EMV 2nd Generation, Version 1.0, Sept. 2014