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.
Related
I am trying to write a PC application (Windows, .NET) that identifies students on the basis of some card equipped with RFID identification to build lecture attendance registers. Currently I have a Stronglink SL040A RFID reader (http://www.stronglink-rfid.com/en/rfid-modules/sl040.html), which operates as a HID and sends the data as a series of keystrokes.
The system works perfectly with older cards like Mifare 1K classic (even with PayPass credit cards). The new student cards (and identity cards) issued by the Hungarian authorities, however, contain Mifare PlusX 4K chips, which seem to send a new key every time one uses the card. I have tried experimenting with the settings the configuration tool of the reader offers, but to no avail. I can make the 1K classic cards send a much longer key by changing the end block parameter but the PlusX 4K keeps sending the shorter, and painfully non-consistent, keys.
I am a physicist without a deeper understanding of these chips and RFID authentication in general – I am just trying to make a job done that seemed easy at the beginning. I have no intention of cracking or abusing these cards in any way, I am just trying to find some block of data on the card that stays consistent upon each use, does not require complicated authentication protocols but is unique between different cards.
Is it possible or is it against the philosophy of these chips? If possible, shall I have to buy a new reader or can I make it do what I need?
Your thoughts are much appreciated.
From the MiFare PlusX 4K datasheet:
Section 8.2:
There are three different versions of the PICC. The UID is programmed into a locked part
of the NV-memory reserved for the manufacturer:
• unique 7-byte serial number
• unique 4-byte serial number
• non-unique 4-byte serial number
Due to security and system requirements, these bytes are write-protected after being
programmed by the PICC manufacturer at production.
...
During personalization, the PICC can be configured to support Random ID in security
level 3. The user can configure whether Random ID or fixed UID shall be used. According
to ISO/IEC 14443-3 the first anticollision loop (see Ref. 5) returns the Random Number
Tag 08h, the 3-byte Random Number and the BCC, if Random ID is used. The retrieval of
the UID in this case can be done using the Virtual Card Support Last command, see
Ref. 3 or by reading out block 0.
From what you have described, it appears that the cards are running in Security Level 3, and unfortunately, the backwards-compatible part of the card only exists at lower security levels. The mentioned command of Virtual Card Support Last is also only available after level 3 authentication.
I'm afraid what you want to do appears impossible unless you can use the ISO/IEC 14443-4 protocol layer, which I think would let you authenticate at level 3? The relevant data appears to be in section 8.7, and involves AES authentication.
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.
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.
I've been fiddeling around with a bluetooth elm327 device I bought a few months ago and am able to get standard obd infos like vin, rpm, speed etc.
But as I just read about recently obd2 and can are not the same. I've tried to sniff on my can bus with th AT MA command, but I get no response, so I guess the can network is decoupled from the obd2 interface. Is there any chance to get access to the can network? Or might I need a different device to do so?
Maybe this info helps: I have a 2011 Skoda.
On many modern vehicles there are actually multiple CAN buses controlling the numerous functions needed by the car. Some of these CAN buses are high-speed for important systems like engine control, and some are low-speed for less critical functions such as climate control (or in your case, diagnostics through the OBD2 port). These multiple CAN buses are usually interconnected through a gateway device in the car that arbitrates which CAN messages can be sent between buses. This is a safety net that prevents lower priority CAN buses from interfering with the more critical CAN buses.
In an example case, the CAN bus used for engine control may be able to communicate with the radio CAN bus so that the radio volume gets increased when the engine is revving to higher RPMs for comfort reasons. This would likely be a one-way connection though the gateway though, as it would be in the interest of safety to not allow the radio's CAN bus to send signals back to the engine (this could lead to potential problems if using aftermarket radios for example).
As a result of everything mentioned above, a connection to the OBD2 port's CAN lines most likely will not have full access to the complete CAN network on your car. One way to confirm this would be to look for the Factory Service Manual for your particular vehicle to see how the CAN bus(es) are setup for your car (there are actually quite a few cars that operate on only a single CAN bus in order to cut costs).
Keep in mind that as an alternative to using the OBD2 port, you can always tap directly into the CAN bus that you are interested in. For example, if you remove the radio from your car to expose the radio harness, you can usually tap directly into the CAN lines for the radio bus with the correct equipment.
Hope this helps!
If your vehicle uses the CAN protocol then you shold be able to issue atma from the elm327 device.
Here are the conditions I met to get an ATMA dump:
my vehicle supports protocol 6 -- iso 15765-4 can-11 (500 kbaud)
ATSP6 // I am using protocol 6, not auto mode
ATSH7E0 // now I am talking to the engine ECU
ATMA // returned a page full of data before getting a buffer full message
We develop a Win32 program (=host) which allows 3rd party to write plug-ins. As some plug-ins contains valuable piece of code (for example, high quality video scalar), the 3rd parties want to limit their plug-in to work only with our host program.
Our idea is to use Microsoft Authenticode technology to sign the host. Then, the 3rd parties are asked to implement the following algorithms to check the host. (The 3rd parties are expected to do sufficient code obfuscation for the algorithm).
Use WinVerifyTrust() API to verify the certificate of the host is valid (= Not revoked, not tampered, etc).
Verify the certificate that the subject is our company.
The question is about step (2). The 3rd parties cannot simply check thumb print or serial number because the digital certificate of the host will be renewed after the certificate expiration date.
My idea is to check parts of subject's distinguished name, specifically "country (C)" and "common name (CN)", assuming that there is no company name confliction in the United States. We shouldn't check other attributes such as state and city because our company might move - in fact, we have moved from one city to another just a year ago.
Question: Is it good way to accomplish the goal?
While the scheme is workable, it's possible to relatively easily circumvent protection by just patching plugins so that they ignore the signature or skip signature verification altogether.
What is even more important, - if you plan to have multiple plugins/vendors, you would have hard time ensuring that all vendors obfuscate validation code right.
Then, I'd say that it can be against plugin vendor's interest to limit their plugin to your application only - if they want bigger market, they might want to have the same plugin run on wider scope of hosts.