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
Related
I'm using BTool, together with a TI Launchpad and the nRF Connect mobile app on my Samsung S21. I am curious, what type of services nRF Connect can be used, that send notifications to my TI Launchpad whenever their value is changed. Not periodically. Only after their value is changed.
I tried using a Battery Level service, but I'm not sure on how to "subscribe" to that service (how to enable notifications) from BTool.
Any advice?
According to this BTool User Guide I found the process of enabling notifications is as follows:
In order to enable notifications, the client device must write a value of 0x0001 to the client characteristic configuration descriptor (CCCD) for the particular characteristic. The handle for the CCCD immediately follows the characteristic value’s handle. Therefore, a value of 0x0001 must be written to the “handle + 1”.
The Battery Service you created has the UUID 0x180F and you have to get the handle for this characteristic. One way is described in the part about reading a characteristic by UUID.
To do this, you will first need to click the “Read/Write” tab in BTool. Select the option “Read Using Characteristic UUID” under the”sub-procedure” option in the “Characteristic Read” section at the top of the screen. Enter the UUID (note that the LSB is entered first, and the MSB is entered last) in the “Characteristic UUID” box, and click the “Read” button.
You can now access the CCCD using "handle + 1" as described earlier. To enable the notifications just write 0x0001 to that handle.
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.
What i have:
I am running a freeradius server fully configured of how i need it to be. Everything works just fine right now.
What i need:
I need the radius to put the devices in a seperate vlan before authentication and to run a vulnerability scan (nessus / openvas etc) on the devices in this vlan to check for software status ( antivirus etc. )
if the device passes the test the authentication should be done normaly.
if it fails it should be put into a third ( fourth if you count the unauth-vid ) vlan.
can someone tell me if this is doable in freeradius ?
thanks in advance for your answers
Yes. But this is a very broad question and is dependent on the networking equipment being used. I'll give you an overview of how I'd design such a system.
In general, you'll have an easier time if you can use the same DHCP server/IP range for your NAC and full access VLAN. That means you don't have to signal the higher networking layers in the client that there's been a state change, you can swap out VLANs behind the scenes to change what they can access.
You'd set up a database with an entry for each client. This doesn't have to be pre-populated, it could be populated during the first auth attempt. Part of each client entry would be a status field detailing when they last completed NAC.
You'd also need an accounting database, to store information about where each client is connected to the network.
If the client had never completed NAC checks before, you'd assign the client to the NAC VLAN, and signal your NAC processes to start interrogating it.
FreeRADIUS can act as both a RADIUS and DHCPv4 server, so you'd probably do signal the NAC process from the DHCPv4 side because then you'd know what IP the client received.
Binding the RADIUS and DHCPv4 sides can be done in a couple of ways. The most obvious is MAC, another common way is NAS/Port ID using the accounting table.
Once the NAC checks had completed, you'd have the NAC process write out a receipt in detail file format, and have that read back in by a detail file listener (there are examples of this in sites-available/ in the 'decoupled-accounting' virtual server files). When reading those entries back in, you'd change the state in the database, and send a CoA packet to the switch using information from the accounting database to identify the client. This would flip the VLAN and allow them to the standard set of networking resources.
I know this is very high level, documenting it properly would probably exceed StackOverflow's character limit. If you need more help with this, I suggest you research what I've described above and then start asking the RADIUS related questions on the FreeRADIUS user's mailing list https://freeradius.org/support/.
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 am writing a build script which has some password protected files (keys). I need a way to prompt the user once for the password and then use this key across multiple scripts. These scripts do not live inside the same shell, and may spawn other windows via dbus. I can then send them commands, one of which must have access to the password.
I have this working already, but at a few points the passphrase is either used directly on a command-line (passed via dbus), or is put into a file (the name then passed to the other script). Both of these are less secure than I want*. The command-line ends up in a history which may be stored in a file, as well as appearing in the process list, and the second option stores in a file which can be read by somebody else.
Is there some standard way to create a temporary communications channel between two processes which could communicate the password and not be intercepted by another user on the system (including root)?
*Note: This is primarily an exercise to be fully secure. For my current project the temporary in-file storage of the password is okay.
Setting "root being all-powerful" aside, I would imagine that a Private DBus Connection would do the trick although the documentation I could find seems a little light on what exactly makes a private connection private.
However, the DBus Specification, more specifically, the Message Bus Specification subsection on eavesdropping says in part:
Receiving a unicast message whose DESTINATION indicates a different
recipient is called eavesdropping. On a message bus which acts as a
security boundary (like the standard system bus), the security policy
should usually prevent eavesdropping, since unicast messages are
normally kept private and may contain security-sensitive information.
So you may not even need to use private connections which incur more overhead costs. But on a risk/reward basis with security being paramount, that may be the more secure alternative for you. Hope that helps.