I am having a problem with the EXTERNAL AUTHENTICATE process on my EMV card. When I authenticate the card to the host, the host responds failed : Card Cryptogram Verification Error. Card cryptogram is obtained from the previous process to the card : INITIALIZE UPDATE.
INITIALIZE UPDATE response
Key Diversification Data (10 bytes)
Key Information (2 bytes)
Sequence Counter (2 bytes)
Card Challenge (6 bytes)
Card Cryptogram (8 bytes)
After we discussed with the host team, there might be a process that does not match in the Card Cryptogram calculation.
So we are looking for algorithms or formulas to calculate Cryptogram cards manually.
Is there an algorithm or formula for manually calculating Card Cryptogram?
Instead of INITIALIZE UPDATE data response.
My reference :
How can I check INITIALIZE UPDATE and EXTERNAL AUTHENTICATE correctness?
I don't see the point. If the GP doesn't handle the INITIALIZE UPDATE command then it won't establish the security context. Computing the cryptogram is in that case no use at all. I don't think you have direct - or at least enough - access to the keys from the applet that acts as a security domain either, so retrieving the keys to perform the calculation should not be possible.
Really, the onus is on the host to fix the issue, not the card. Usually cards are implemented and tested against the specs, so there must be a missing option or the host may be using a different SCP which results in the cryptogram failing.
Related
Prof. Palam asked to submit the assignment (Answer prepared after the deadline are
not considered) onto a server/ drive to which the whole students-group have access (read
and write not delete). State precisely (step wise) the protocol for submission and
verification. Note that Prof. Palam has no individual shared key with the students for
scalability issues. Justify your protocol
I have written an applet in my java card and the other applet in my SAM. I want to create mutual authentication by sending random number created each side.
The model of reader is:
c:\>gp.exe -all -d
# Detected readers from SunPCSC
[*] ACS ACR1281 1S Dual Reader PICC 0
[*] ACS ACR1281 1S Dual Reader SAM 0
I select applet on SAM ,create random number and send out. Then I select applet on java card creating string with random of SAM and new random creation by card and send the mixed random.
So I should again select applet on SAM to check the random, but as my randoms are in transient Clear_ON_RESET Memory, they gone.
I need random numbers in transient CLEAR_ON_RESET Memory.And I use gp.exe for sending APDU's.
Is there any way that I can have both SAM and Card selected? I guess there should be a way to have both them up.
If you've got different (logical)) reader devices then there is no need to close the channel to either one of them while using the other. You should be able to use them concurrently, even from the same thread.
The problem is using gp.exe which is a tool not written for such usage. Please code an application, for instance using Java & javax.smartcardio instead.
I'm trying to read some data from the secure element in the SIM of a global platform 2.2 card.
My SELECT command of the applet is successful 90,00 with some PDOL data in the response. However when I send Get Processing Options it returns 6D00. It seems the Security Domain is still in charge and does not understand the GPO command.
My investigation says applet specific commands needs to go over a secure channel, while the CRS runs on the basic channel. Is this requirement true even if the card is not being accessed over the contactless interface?
First of all verify that your applet must be selected on same I/O interface and the same logical channel on which you are sending the command.
The status word '6D00' shows that the command sent over another applet or SD that does not understand it instead of secure channel initiation requirement.
And yes if you are communicating with secured card like and Secure element then you need to initiate scp session.
SELECT APDU should be sent first with correct AID.
If AID belongs to the EMV card, response should come with status SW 90 00 with data area. Processing Options Data Object List in data area should be properly parsed and GET PROCESSING OPTIONS should be constructed with required parameters (Terminal
Transaction Qualifiers,Amount, Authorized , Unpredictable Number etc.)
Try this TLV utilities and see the options list:
9F38 Processing Options Data Object List (PDOL)
9F66049F02069F37045F2A029A03
I have a public computer that is used in an ATM sort of fashion. When a certain action occurs (person inserts money), the program I've written on the computer sends a request to a trusted server which does a very critical task (transfers money).
I'm wondering, since I have to communicate to a server to start the critical task, the credentials to communicate with it are stored on this public computer. How do I prevent hackers from obtaining this information and running the critical task with their own parameters?
HSM (Hardware Security Modules) are designed to store keys safely:
A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.
HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Each module contains one or more secure cryptoprocessor chips to prevent tampering and bus probing.
Impossible in general
If your user has access to this PC, they can easily insert fake money. Your model is doomed.
Minimize attack surface
This PC ought to have unique token (a permanent cookie is enough), and sever will refuse a request without a valid cookie. Server maintains database of device types, and this ATM-PC is only allowed certain operations (deposit money up to NNN units). Ideally it is also rate-limited (at most once per 3 seconds).
What mechanisms exist already for designing a P2P architecture, in which the different nodes do work separately, in order to split a task (say distributed rendering of a 3D image), but unlike torrents, they don't get to see, or hijack the contents of the packets being transmitted? Only the original task requester is entitled to view the? results of the complete task.
Any working implementations on that principle already?
EDIT: Maybe I formulated the question wrongly. The idea is that even when they are able to work on the contents of the separate packets being sent, the separate nodes never get the chance to assemble the whole picture. Only the one requesting the task is supposed to do this.
If you have direct P2P connections (no "promiscuous" or "multicasting" sort of mode), the receiving peers should only "see" the data sent to them, nothing else.
If you have relay servers on the way and you are worried that they can sniff the data, I believe encryption is the way to go.
What we do is that peer A transmits data to peer B in an S/MIME envelope: the content is signed with the Private Key of Peer A and encrypted with the public Key of Peer B.
Only peer B can decrypt the data and is guaranteed that peer A actually sent the data.
This whole process is costly CPU and byte wise and may not be appropriate for your application. It also requires some form of key management infrastructure: peers need to subscribe to a community which issues certificates for instance.
But the basic idea is there: asymetric encryption with a key or shared secret encryption.