I send PowerOn CCID command on card insertion to receive ATR. But instead I always get this error:
PC_to_RDR_IccPowerOn (00h Automatic):
bStatus: 0x0
bError: 0x80
Error 80h according to CCID spec "Reserved for future use".
But same code working correctly with other CCID device I have and this device works with other apps. So how I can find what I'm doing wrong?
I have tried different voltages 3v,5v, 1.8v, but for all of them I get exactly same error.
Even when this happens I get correct ATR. So then I'm trying to send APDU (select non existing file to warm up connection) and then I get:
Slot Status: 40h "An ICC is present and inactive (not activated or
shut down by hardware error)"
So what does it mean "inactive" What I should do?
CCID device descriptor:
CCID Device Descriptor:
bcdCCID: 0110
5V Support true
3V Support true
1.8V Support true
dwDefaultClock: 3.75 MHz
dwMaximumClock: 7.5 MHz
dwDataRate: 10080 bps
dwMaxDataRate: 10080 bps
T0 Support true
T1 Support true
dwFeatures * 0x4c4b400
* Automatic IFSD exchange as first exchange
* Short and Extended APDU exchange level support
dwMaxCCIDMessageLength 271 bytes
wLcdLayout 0000
bMaxCCIDBusySlots 01
Related
I am trying to get CAN communication running via an external SBC (TLE9263) board.
Microcontroller: S32K312
Ext. SBC board: TLE9263_EVB_2
Without SBC, i.e., using a standard external CAN transceiver TJA1057GT, CAN communication is running.
With SBC, some messages are received once, but then the SBC transceiver goes down, and CANIF_E_FATAL Det error occurs (Call Stack).
I configured the SBC registers as follows: SBC registers configuration
The following values are observed on the SPI-MOSI signal:
41 00 - SUP_STAT_1
82 00 - HW_CTRL
81 1F - M_S_CTRL
84 07 - BUS_CTRL_1
85 00 - BUS_CTRL_2
83 82 - WD_CTRL
The above observed values are expected in my opinion. What could be the cause of communication not working?
Additionally (not sure if this is relevant), the Fail Output LEDs on the TLE9263 board, FO1 and FO3 are ON as soon as the board is powered, and FO2 is blinking, and this status of the LEDs remains the same when the software is run.
USB soundcard Creative X-Fi switches from USB1.1 to USB2.0 when its proprietary windows driver is used, allowing faster samplerates in its USB2 configuration. A capture of USB packets by wireshark shows several commands are sent by the proprietary driver just before the device disconnects and re-connects at USB2. I am trying to replay the commands to the device in linux, to be able to add the same feature to the existing linux usb-audio driver.
I want to use python, presumably the libusb1 wrapper around libusb-1 library. The captured packet shows the driver sends usb control request to endpoint 0x80 with wIndex 0. Please is there a way to format and send such a packet with libusb-1? I found this answer https://stackoverflow.com/a/39343813/15717902 but do not know if it still holds.
The captured packet:
USB URB
[Source: host]
[Destination: 3.5.0]
USBPcap pseudoheader length: 28
IRP ID: 0xfffffa8009ebd3e0
IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
URB Function: URB_FUNCTION_VENDOR_OTHER (0x0020)
IRP information: 0x00, Direction: FDO -> PDO
URB bus id: 3
Device address: 5
Endpoint: 0x80, Direction: IN
URB transfer type: URB_CONTROL (0x02)
Packet Data Length: 8
[Response in: 20]
Control transfer stage: Setup (0)
[bInterfaceClass: Unknown (0xffff)]
Setup Data
bmRequestType: 0xc3
bRequest: 42
wValue: 0x0000
wIndex: 0 (0x0000)
wLength: 2
I have empty JavaCOS A40 smartcard and want make it a PKCS PKI card.
I'm going to use it as ssh key and for e-contracts signing. Russia don't provide smartcard-based e-id for citizens like EU countries do. Commercial e-signature providers are selling some sort of password-protected usb drives, that's unsafe to use, because you can easily export private key. Also they sell normal smartcards, but they are really expensive(x10-x20 than empty javacard) and short-living(about 1 year). So i want to make my own PKI card based on RSA algorhitms from javacard.
Now my javacard is in state OP_READY and I don't changed it, because changes are irreversible. It use default key and anyone can upload anything. I use ACR38U reader with pcsc linux driver on Ubuntu and it works as expected, so I used GlobalPlatformPro to upload PKI IsoApplet as default. So GP's output:
java -jar gp.jar -list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000003000000 (OP_READY)
Privs: SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement
APP: F276A288BCFBA69D34F31001 (SELECTABLE)
Privs: CardReset
PKG: F276A288BCFBA69D34F310 (LOADED)
Version: 1.0
Applet: F276A288BCFBA69D34F31001
cardpeek successfully connects to it and I can send low-level commands to applet
But when I try to connect to card and applet using opensc prober to see Answer-To-Request(ATR), it fails opensc-tool --reader 0 --atr. See maximum debug info
Shortened version:
opensc-tool --reader 0 --atr -vv
Connecting to card in reader ACS ACR 38U-CCID 00 00...
0x7fc849e7e740 22:17:14.634 [opensc-tool] card.c:200:sc_connect_card: called
0x7fc849e7e740 22:17:14.634 [opensc-tool] card-entersafe.c:138:entersafe_match_card: called
Failed to connect to card: Card command failed
0x7fc849e7e740 22:17:14.797 [opensc-tool] ctx.c:870:sc_release_context: called
According to manufacturer info, card is supporting T=0 over ISO7816, but opensc tries to communicate with T=1. So how I can fix this?
Seems, that opensc tools are not customizable. I need to use pkcs15-crypt, but it can't connect. May I change drivers, recompile opensc with patches, or use another utility? How another ways I can use to work with OpenPGP for example?
Your problem is certainly not with the transport protocol because it communicates an APDU with the card. When looking at the logging it seems to incorrectly guess from the ATR that the card is an epass2003:
0x7f175a21e740 22:14:13.904 [opensc-tool] card.c:287:sc_connect_card: matched: epass2003
then execute a command to it:
0x7f175a21e740 22:14:13.904 [opensc-tool] apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:86, data(0) (nil)
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:283:pcsc_transmit: reader 'ACS ACR 38U-CCID 00 00'
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:284:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 86 00 .....
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:212:pcsc_internal_transmit: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:293:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:390:sc_single_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:543:sc_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] card.c:459:sc_unlock: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:662:pcsc_unlock: called
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:189:epass2003_check_sw: Instruction code not supported or invalid
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:1118:get_data: get_data failed: -1204 (Unsupported INS byte in APDU)
Now this command is executed over the communication channel in T=1 (it's very unlikely that the card just supports T=0 if it also supports T=CL, because T=CL and T=1 are very much alike - at the higher level). Not only that, it correctly returns a result, even if that is higher level error condition: 6D00 meaning instruction not supported.
This leads to the high lever error condition:
Failed to connect to card: Card command failed
which is slightly misleading, because it certainly connected to the card, it just wasn't able to get any data from it using a GET DATA command. This isn't that strange because it didn't first select any applet and GET DATA (with INS-truction CA) is not likely to be present in the root folder / applet.
TL;DR your connection is fine, now start programming it by issuing GlobalPlatform card manager commands to it. If possible use a different tool or get opensc tools to skip the identification phase / initial commands to it.
IsoApplet and OpenPGP are two different world. For OpenPGP support, look at either SmartPGP by ANSSI-FR on github or ykneo-openpgp (also on Github).
For signatures, you also do not need pkcs15-crypt but should work via PKCS#11 library instead.
For this specific reason - the card being matched as epass, disable the epass driver in opensc.conf.
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
I have kannel SMPP (kannel.org) and receive SMS statuses by param: %d
And here is table:
16 = not delivered to smsc
8 = you submitted to smsc. ie smsc tell
kannel he has the msg
4 = msg is in smsc queue. ie smsc tell kannel he queued the msg in its queue.
2 = failed 1 = delivered to phone
But here is very low information. How I can receive more information about (wrong number or something like what)? Now is just failed and whats all, if we want to know why failed we must ask our partners support.
More detailed information on delivery error you can fetch from the following sources:
network_error_code TLV (0x0423) - see p. 5.3.2.31 of SMPP v3.4 specification
text part of DLR message (%A in dlr-url)
command_status in case of rejection (represented as "NACK/$code"
Example of text part in DLR:
id:0832095221 sub:001 dlvrd:000 submit date:1203311115 done date:1204010436 stat:UNDELIV err:011 text:some text here
Here you can see 011 error code in undeliverable message.
However there are many vendor specific issues you need to discover with each new SMSC. And no strict requirements in SMPP specification to information to represented in DLR.
For your DLR URL add this:
dlr_mask=31
dlr_url=....?answer=%A&status=%d
Where DLR bitmask means:
1: Received by phone
2: Failure to deliver to phone
4: Queued for delivery
8: Accepted by other SMSC
16: Rejected by other SMSC
If you get a 16, or your get a 2 it'll look like this:
status=<2 or 16 here>
answer=NACK//
The get a table mapping hex_code to its vendor-specific meaning from the carrier