EMV Offline Data Authentication - CDA Mode 3 - emv

The EMV Spec 4.3 Vol 2 defines the different modes for CDA ("Combined Data Authentication") with a chart:
+----+-------------------+-----------------------------------+
|Mode|Request CDA on ARQC|Request CDA on 2nd GEN AC (TC) |
| | |after approved online authorisation|
+----+-------------------+-----------------------------------+
| 1 | Yes | Yes |
| 2 | Yes | No |
| 3 | No | No |
| 4 | No | Yes |
+----+-------------------+-----------------------------------+
My question:
If a PinPad is in CDA Mode 3, does it actually perform the data authentication step at all?
The PinPad I am using is in CDA Mode 3 and it appears to be doing so sometime in the ARPC validation/TC generation step as evidenced by the Byte 1, Bit 8 of the TVR being set to zero at that time. However, the chart above would lead me to believe that it is not.
Unfortunately, I don't have a UL or Collis tool to get inside the PinPad to see the PinPad/chip flow.

Short answer to your question is YES - the acceptance device will perform card authentication. When it comes to ODA, it might be also SDA (already obsolete) or DDA that will happen regardless of CDA mode.
CDA mode 3 means only that ODA will not be performed if other CAM (Card Authentication Method) is available. It will still happen for offline accepted transactions.
To clarify, the Card Authentication Methods:
Offline CAM = PKI based Offline Data Authentication which CDA is an example of
Online CAM = symmetric cryptography based verification of cryptograms during online communication.
In early days of EMV implementation acceptance devices had quite limited processing power - they were mostly based on 8-bit microcontrollers which meant it took ages to perform RSA with larger modulus. That's why CDA mode 3 was introduced - to avoid performing resource-heavy offline CAM when online CAM is available - in online transactions. That was perceived an optimization in the time and was recommended by schemes and EMVCo.
In today terms, CDA mode 1 is widely adopted and I don't remember any recent Type Approvals with CDA mode 3. If you have a device with it, you might be dealing with an old device with an expired approval.
ARPC verification (Issuer Authentication step) you mention is not reflected in TVR B1b8 - it's only an indication that ODA was not performed, which (apart from CDA mode 3 situation) might also be when card and terminal do not support any common authentication method (some online-only terminals do not need to perform ODA; some non-expiring cards do not support ODA as well). Issuer Authentication might be explicit (when AIP in the card indicates it and you received ARPC in the response), but might happen also implicitly (when AIP doesn't indicate it but card requests ARPC in CDOL2) and you might not see it indicated in TVR.

Related

M-TIP18 Test 01 scenario 01

I'm working on the M-TIP - EMVCo L3 build 280 certification and on Test case 18 01 01
I keep receiving an error on the second generation of AC, the terminal keeps requesting the TC instead of AAC when the issuer responded with response 85,
I just need to know if there's any solution I can do on the ATM to fix this issue.
The ATM is Diebold Nixdorf WIN10
Well, it's definitively not a Stack Overflow question, but I'll try to help you anyway.
RC85 is a 'Not decline' type of answer and it might be a matter of type of transaction whether it is considered an acceptance which might be confusing in some situations. This is a logical result of the transaction but terminal-card interface do not always reflect it as there is a differentiation between fully EMV financial transactions and those not defined by EMV. Transactions that consider RC85 as accepted are not defined by EMV specification and should result in AAC regardless of the the logical result.
You don't mention what type of application is running on your ATM, what host you are interfacing and what protocol is used for that. If you are using NDC/DDC, you should first look at your host and download to see if AAC is really what is expected (in my experience, this case is rarely covered correctly in first run). If you have certainty you have it right on the host side or you are using thick client application that handles that logic internally on device side, try talking to your ATM application vendor.

9F1D is it a configuraiton or derived from other config

When checking a payment app static config I found something I consider a divergence.
<ttq>A2000000</ttq>
<term_caps>E06808</term_caps>
<txn_tag_data>9f1d082CB8000000000000</txn_tag_data>
which is sent to kernel during a CTLS transaction as:
9F3303E06808 -> SET 004000 (Byte 2 Bit 7) Enciphered PIN for online verification
9F6604A2000000 -> NOT SET 040000 (Byte 1 Bit 3) Online PIN supported
9f1D082CB8000000000000 -> NOT SET (Byte 1 Bit 7) Enciphered PIN verified online (Contactless)
I couldn't find the information in EMV books if the tags must be consistent.
If enciphered online PIN is set in terminal capabilities shouldn't it be also set in TTQ and 9F1D?
These tags referred to different card schemes. Up to your terminal config if you need to enable/disable Online PIN with different card schemes requirements and between EMV Contact and Contactless capabilities.
Tag 0x9F66 used by some Card schemes. It is not always Terminal Transaction Qualifiers (TTQ). The meaning is different per scheme Kernel and not always used.
Check details in EMV Contactless Specifications for Payment Systems books.
Tag 0x9F1D Terminal Risk Management Data defined in EMV Contactless Specifications for Payment Systems, Book C-2, Kernel 2 which is MasterCard's PayPass.
It needs to be configured on terminal application at least for MasterCard Contactless related kernel initialization.
In the MTIP 2.0 Build 260 Test plan (current as of 2021) MasterCard also add EMV Contact cases MTIP65.* when terminal need to return this Tag value to the card for EMV Contact transaction withing CDOL1 data.

How can I improve socket hang up when connecting many devices?

I am testing to connect many devices to FIWARE in the following environment.
Each component is deployed in a container on a physical server.
+-------------------------------------------------+
|Comet - Cygnus - Orion - IoTAgentJSON - Mosquitto| - device*N
+-------------------------------------------------+
Under the condition that each device transmits data at 1 msg/sec, the following error occurs at IoTAgent when the number of devices is 350.(That is, 350 msg/sec)
{"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Error found executing update action in Context Broker: Error: socket hang up | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.81037597Z"}
{"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Raising [ORION-ALARM]: {\"code\":\"ECONNRESET\"} | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.810440213Z"}
{"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentJSON.MQTTBinding | srv=n/a | subsrv=n/a | msg=MEASURES-002: Couldn't send the updated values to the Context Broker due to an error: Error: socket hang up | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.810526916Z"}
The result of the requested ps ax | grep contextBroker command is as follows.
ps ax | grep contextBroker
19766 ? Ssl 29:02 /usr/bin/contextBroker -fg -multiservice -ngsiv1Autocast -dbhost mongodb-orion-demo -statCounters -statSemWait -statTiming
Question 1: Where is the cause? IoTAgent? Or Orion? Or MongoDB? Or kernel parameter?
Error found executing update action in Context Broker: Error: socket hang up but there is no error log displayed in Orion.
Question 2: How can I improve the processing performance of FIWARE?
Do you need the scale of IoTAgent?
Do you need to consider Orion's parameters?
I need to consider values ​​such as reqPoolSize and maxConnections with reference to the following URL?
https://fiware-orion.readthedocs.io/en/master/admin/perf_tuning/#http-server-tuning
Do you need the scale of Orion?
How to scale Orion GE?
Question 3: Is there a batch operation on IoT Agent?
On the following page, you should do a batch operation instead of opening a new connection for each entity, but is there such a function in IoTAgent?
ECONNRESET when opening a large number of connection in small time period
It is difficult to provide a right answer, as performance depends on many factors specially in complicated setups involving several components interacting among them. However, I'll try to provide some thoughts and insights based in the information you provide and my previous experience.
With regards to Orion, I'd recommend you to have a look to the documentation on performance tunning. Following the indications in that page you can increase the performance of the component.
However, having said that, I don't think that Orion is the cause of the problem in your case, based on:
Even without performance optimization Orion typically reach a throughput in the order of the ~1,000 tps. It should cope updates at 350 tps without problems.
Orion is not showing error logs. The error logs you have are produced by IOTAgent component, as far as I understand.
Thus, focusing in IOTA, maybe it would be better to use IOTA-UL instead of IOTA-JSON. The UL encoding is more efficient that JSON encoding so you can gain in efficiency. In addition, IOTA-UL allows you to send multimeasures (using # as separator) which I don't know if fits your case but can be seen as a limited form of batch update (see UL documentation for more detail).
If that doesn't work another posibility is to send data directly to Orion using its NGSIv2 API. That would have several advantages:
Simplified setup (two pieces less: MQTT broker and IOTAgent)
Under same resource conditions, Orion native performance is typically higher than IOTAgents performance (as I mention before ~1,000 tps or even higher after applying performance optimizations)
NGSIv2 API provides a batch update operation (look for POST /v2/op/update in the NGSIv2 specification document cited above)

TVR bits match TAC Online, but transaction does NOT go online?

I have a scenario where the EMV Contactless card image (American Express) SHOULD decline offline; however, the Ingenico PinPad is going online and approving and the VeriFone is declining offline.
Even though, this scenario SHOULD decline offline - I am convinced this scenario should go ONLINE. I think the VeriFone is a false-positive and the Ingenico is doing the right thing by going ONLINE.
The purpose of this scenario is to ensure that the terminal declines a transaction offline when CDA fails.
The card image has an IAC Denial of "0000000000" and IAC Online of "F470C49800".
The TVR that gets generated during 1AC is '0400008000'.
The TAC Denial is set to "0010000000" and the TAC Online is set to "DE00FC9800".
TVR = "0400008000"
IAC_Denial = "0000000000"
TAC_Denial = "0010000000"
IAC_Online = "F470C49800"
TAC_Online = "DE00FC9800"
When comparing the TVR to the TAC Denial (which should happen first) according to the EMV Book 3 - Terminal Action Analysis - there are NO matching bits. So the next thing that should happen is the TVR should be matched with the TAC Online. When comparing the bits from the TVR to the TAC Online - the bits that match are: "CDA Failed, Exceeds Floor Limit".
This indicates to me that this should go ONLINE; however, as previously stated the scenario is ensuring that it declines OFFLINE.
In a nutshell, the VeriFone PinPad is giving a false-positive by declining OFFLINE without using the Terminal Action Analysis logic.
However, the Ingenico seems to be doing the right thing by going ONLINE.
Is there something that I am missing?
Is there any configurations that can override the Terminal Action Analysis from matching the TVR to TACs to prevent a transaction to go online?
Could this be an issue with the VeriFone kernel?
Thanks.
I often got this error when my POS terminal was not properly configured.
Often, scenarios like this one will have thresholds to configure in your terminal accordingly to its standards. For instance, my terminal was configured accordingly to SEPA-FAST standards.
There was a threshold for the maximum amount value to approve offline. This is useful for merchants that want to approve small amounts offline for effectiveness and speed when they have long lines of customers to process. Think of a cafeteria or a bus line. Of course, this is slightly risky and many merchants won't approve high amounts without an online approval to reduce their loss due to invalid/fraudulent payments.
In my opinion, your offline threshold looks fine. The transaction amount exceeds it and it is refused offline for the obvious reasons I explained to you before.
Perhaps your maximum threshold is badly configured. Most scenarios require you to set a maximum amount threshold over which the transaction is refused offline.
One other thing that could be wrong is your EMV Terminal capabilities 0x9F33 that supports Online PIN authentication and shouldn't. Maybe you aren't using the terminal prescribed by the scenario. What is your CVM? Should it be supported by your terminal? There is also the EMV Terminal Transaction Qualifiers (TTQ) field 0x0F66 for NFC transactions that plays a similar role in defining what a terminal can and cannot do. Maybe your terminal should be offline only in this scenario. This could happen for pizza deliveries or in situations where an internet connexion is not available.

EMV Book 4 Annex A2 Terminal Capabilities Byte-1 Missing bit for Contactless

I was going through EMV books and updates done for Contactless and didn't find any "reserved" bit in Book 4 Annex A2: Terminal Capabilities Byte-1 to figure out if the terminal is capable of performing "Contactless" transaction.
Am I missing anything? My requirement is to be able to read tag 9F33 and figure out if the terminal had contactless capability. Is there any other way to find that out?
Thanks!
I think it is a little awkward to expect understanding existence of contactless interface from contact interface.
9F33 is 3 bytes data.
Byte 1 (Card Data Input Capability):
bit 8: 1 = Manual key entry
bit 7: 1 = Magnetic stripe
bit 6: 1 = IC with contacts
bits 5–1: RFU (00000)
During contact transaction knowing that terminal is capable of Magnetic stripe is important because there is a chance of fallback scenario that you have to make a magnetic stripe transaction. But contactless interface is more advanced then contact transaction so there is no need to know that terminal is contactless capable.