3

Basically the title but in more broad context: is there a way for the terminal to verify that the AIP is the one really sent by the card and not replaced in man-in-the-middle attack?

Ognyan
  • 13,452
  • 5
  • 64
  • 82

2 Answers2

3

Short answer - yes. SDA is 'embedded' in the ICC Public Key recovery process. AIP will always be included if SDA Tag list is present in the card. You can find details in EMV Book 2 chapter 6.4

Michal Gluchowski
  • 1,197
  • 8
  • 16
  • In the case of contactless transaction on online only, EMV mode only terminal I can't see a code path for the Mastercard or Visa kernels where they are obligated to perform SDA. Am I missing something? (Or perhaps you are talking only for contact interface transactions?) – Ognyan Jun 05 '18 at 13:57
  • And also 'No CDA supported' or turned off in the terminal configuration. – Ognyan Jun 05 '18 at 14:03
  • OR AIP is modified in man-in-the middle attack to indicate that the card is not supporting CDA. – Ognyan Jun 05 '18 at 14:09
  • It's not SDA, but simply the authentication of static data in the same way as is done during SDA. Dynamic Data authentication done during DDA or CDA is performed using card public key that is recovered from ICC certificate (type 04). During the recovery process done using the issuer public key you authenticate the static data (step 5 of the procedure as described by EMVCo). – Michal Gluchowski Jun 06 '18 at 08:43
  • ICC Public key recovery process (that validates static data) is shared among all offline data authentication processes - contact, contactless, DDA, CDA, fDDA, ... If you modify AIP to exclude CDA, the terminal will try to perform it, but you will still fail SDA and DDA. If you switch off ODA completely, the TVR B1b8 shall be set by the terminal. On Mastercard contactless all terminals are required to support CDA, so you will not be able to switch it off and still be compliant. – Michal Gluchowski Jun 06 '18 at 08:51
  • Sorry, my bad, I did not explained good enough: In online only, EMV mode only terminal if the AIP is intercepted and replaced with AIP that says 'no CDA support' at least the Mastercard kernel will disable CDA because it is not supported by the card. Later it will not try to perform it. And because there is no CDA also ICC Public key recovery processed. Probably I am missing something. Anyway, thank you for your time and input. I will have to read more about this problem and you gave me direction where to look. – Ognyan Jun 06 '18 at 10:27
  • Correction: "And because there is no CDA also there is no ICC Public key recovery processing." – Ognyan Jun 06 '18 at 10:36
  • 1
    With online only profile you do not have that issue at all as online authentication using symmetric cryptography (ARQC validation) is considered a stronger security control than ODA. – Michal Gluchowski Jun 06 '18 at 10:39
2

There could be two ways to get AIP apart from GPO response:

  1. During Static Data Authentication you can retrieve the value of AIP from ICC public key certificate (As mentioned above). But if Offline Data Authentication is not supported ( profile is online only ) then this trick will not work may be.

  2. You can simply send Get Data Command for AIP ( Tag 82 ) to get the value of AIP (should work most of the time).

Gaurav Shukla
  • 412
  • 1
  • 4
  • 11
  • Yes, the profile is online only, and according to the specs (Book C-2) Offline Data Authentication is not performed. About (2): If someone replaced the AIP at first he might replace it again? Also at least for the standard kernels they are not required to request AIP again. Frankly I am quite confused about this issue - it seems like major security feature can be circumvented... – Ognyan Jun 06 '18 at 10:34
  • @Ognyan When you are saying replace the AIP, what does it means for you..?? Is it like doing PUT DATA on AIP or just altered value of AIP by middle man. Yes I do agree that standard kernel don't ask for AIP via get data normally..!! – Gaurav Shukla Jun 06 '18 at 10:45
  • For dealing this kind of situations, Payment schemes has the concept of Card Issuer Action Codes(Denial, Default & Online). These are regulations set by issuer to help the application for taking decisions. For example, if original AIP is states that Offline Data Authentication (SDA/DDA/CDA) is supported then definitely CIAC must be set like, if ODA is not performed then transaction must not be approved. Either it will go online or decline. So if somebody is altering AIP like no ODA supported then during GAC command card will check the current application status and accordingly decline the txn – Gaurav Shukla Jun 06 '18 at 11:29
  • 1
    Basically AIP defines some features supported by application. Terminal will proceed the transaction as stated in AIP. means if ODA not supported, terminal will never ask for ODA, similar for pin verification & so on. CIACs are there to support the application to take the decision while generating application cryptogram. Similarly we have Terminal Action Codes from terminal side to help the terminals to take the decisions. Not possible to bypass AIP, since AIP & CIACs are in line to each other & responsibility of issuer to personalize in such a way. – Gaurav Shukla Jun 06 '18 at 11:34