OpenSC fails to connect javacard with PKCS applet - cryptography

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.

Related

Can an end point is connected to more than one router in a NoC topology in gem5 garnet3.0?

I am running gem5 version 22.0.0.2. I operate Garnet in a standalone manner in conjunction with the Garnet Synthetic Traffic injector. I want to emulate a routerless NoC so I guess I need to connect an end point (e.g, Cores, Caches, Directories) to more than one "local" router. I just use a python configuration to configure the topology. But when I do this, there is a runtime error:
build/NULL/mem/ruby/network/garnet/GarnetNetwork.cc:125: info: Garnet version 3.0
build/NULL/base/stats/group.cc:121: panic: panic condition statGroups.find(name) != statGroups.end() occurred: Stats of the same group share the same name `power_state`.
Memory Usage: 692360 KBytes
Program aborted at tick 0
Here is a description from the gem5 documentation: "Each network interface is connected to one or more “local” routers which is could be connected through an “External” link." Here is the link:https://www.gem5.org/documentation/general_docs/ruby/heterogarnet/
Here is the constructor of Stats::Group
Group(Group *parent, const char *name = nullptr)
Here is a description from the gem5 documentation: "there are special cases where the parent group may be null. One such special case is SimObjects where the Python code performs late binding of the group parent."
Here is the link:https://www.gem5.org/documentation/general_docs/statistics/api.
I guess the error may be related to this, but I don't know the exact reason.
Any help would be appreciated.
Thank you.

MasterCard PIN change issuer script fails, Thales HSM used for MAC generation. EMV

I use Thales Payshield 9000 HSM. So far, all commands has worked and everything has been achieved what i wanted.
Now the problem is when trying to change pin in ATM. Pin change script is generated and format looks like is OK when checking MasterCard docs.
Our pin change script looks like this: 86158424000210PPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMM where 16 P letters are PIN block sent in DE125 and 16 M letters represents MAC. (I masked them, but below will be used data from example)
With this script all looks ok here from my side. Now i suspect the problem is MAC generation.
To generate MAC we use following HSM commands:
HA (generate TAK (its a random key, every time (every PIN change operation) i call this command, key is different)) - the input is: key = PVK key (U+32Hex symbols under LMK), delimiter = ';', keySchemeTmk = 'U', keySchemeLmk = 'U'; Then the TAK key is received
M6 (generate MAC) - input is: modeFlag = 0, inputFormatFlag = 2, macSize = 1, macAlgorithm = 3, paddingMethod = 0, keyType = '003', key = 'Tak key from HA command', messagelength = '0030', message = '8424000210345755BFDC4F2903A392B3E1229A502C892680' (message is concatenated like in the screenshot above: command header + ApplicationtransactionCounter + ARQC + PIN Block) (message data here is from example in screenshot)
So, when those two commands are executed, i receive 16HEX symbols MAC which exatcly i need. So the script is prepared like this: 8424000210 B3E1229A502C8926 422A8FF11056ACD4: header => 8424000210, pinBlock => B3E1229A502C8926 and MAC => 422A8FF11056ACD4
When i go to ATM and do Pin change, my pin never get changed and i receive reversal message.
Also can anyone explain what are those flags, i'm not sure which ones i should use (command M6):
So the questions are:
Is HSM command M6 correct command to generate MAC for PIN change/unblock script? It requires TAK key while MasterCard docs clearly states that it should be done with SMI key.
Is my config for M6 command is not correct when trying to retrieve MAC hash?
Updated
I managed to get KU command working and it brings me response but the PIN change itself is not successfully completed. Below i will show you what request i generate to the KU command:
{
"mode_flag": "3",
"scheme_id": "1",
"mk_smi": "U25A22A6553A7F68ABACBD1E04BBD8889",
"pan": "7891234567891200",
"integrity_session_data": "55BFDC4F2903A392",
"plaintext_message_data_length": "0018",
"plaintext_message": "8424000210345755BFDC4F2903A392B3E1229A502C892680",
"delimiter": ";",
"confidentiality_session_data": "55BFDC4F2903A392",
"offset": "000F",
"cipher_text_message_data_length": "0008",
"cipher_text_message_data": "B3E1229A502C8926",
"delimiter2": ";",
"source_pin_encryption_key_type": "0",
"source_pin_encryption_key": "UBAAAA3488AA6AA564AAC8AA3AAC1AAA2",
"source_pin_block_format_code": "01",
"destination_pin_block_format_code": "35",
"pan2": "891234567891"
}
Keys and sensitive data is masked so the PAN is used here: 5678912345678912 and sequence number 000. For the first pan parameter 14 last PAN digits used + two last digits from sequence number. For pan2 parameter, only 12 last PAN digits used, with check digit excluded.
Am i using correct Offset flag for replacing PIN block in plaintext data with the new encrypted pin block ?
Answering your question, M6 is not what you should call for script generation. It's purely for message integrity when communicating with acceptance devices or other hosts. That's why there is even no option for derivation of keys required for cards.
For EMV cards there are seperate sets of commands for verification of ARQC, generation of ARPC as well as generation of issuer scripts.
For Issuer scripts generation purpose, please have a look at KY command where you shall supply master keys for integrity and confidentiality as well as other parameters (including PAN, PSN, ATC, etc) that are required for session key derivation. There is a particular mode for PIN change command where PINblock is supplied under ZPK or TPK.
You should check precisely security parameters you have set for your cards as there are different algorithms that may be used for session keys derivation (verify what are your card application settings). Cards may also support different MAC length and you should take care of it as well.
I am fighting the same issue.
I may be wrong but speaking to other folks I was told that KU is the one to use for CVN10.
Now, I was also told to only use KU command as it does everything that is needed.
This means it will translate the new pinblock that is coming in from the ATM using the pin key that is stored on the chip.
The only thing I see is that the destination pinblock you use is 35 which is Europay > MC Pay now, but I think you have to use 34 which is the default for offline clear pin.

WPA_supplicant authentication implementation

I need help from someone that have some experience in playing with wpa_supplicant code.
What i understand is that wpa_supplicant dose everything in order for a supplicant to connect to an AP (if that what you what). Hence the steps are as:
Scan
Get scan results
AUTH
ASSOC
4-hand shake
data exchange
As i understand this then the first 4 steps are only managed by wpa_supplicant. That is, wpa_supplicant simply calls the under laying driver to perform these steps and after the main event loop receives the EVENT_ASSOC msg. it starts the 4-handshake.
For my part, it is fine with the first two steps are carried out at the driver, ie., wpa_supplicant send a scan req, the driver perform the scan and feed the scan results.
My question is, is it correct that wpa_supplicant cannot generate the necessary packet and use, e.g., layer 2 (rawsocket) to send authentication request to the AP ? and followed by an associate request ?... shall one simply provides these as a handle from the driver layer ?
as i can see from the code in wpa_supplicant.c
(void wpa_supplicant_associate(struct wpa_supplicant *wpa_s,
struct wpa_bss *bss, struct wpa_ssid *ssid))
that this function calls a function pointer to the selected driver eg. ".associate = wpa_driver_nl80211_associate" and here the driver then send this down to the udnerlaying nl80211 driver code ? .... so wpa_supplicant can not generate these packet by it self ?
I hope that this make any sens, if not please ask :)
Yes, your understanding is correct. To send auth/assoc req, the wpa_supplicant should construct the corresponding NL80211 commands in following different scenarios:
a) in case the SME is maintained in wpa_supplicant
NL80211_CMD_AUTHENTICATE
NL80211_CMD_ASSOCIATE
b) in case the SME is maintained by driver
NL80211_CMD_CONNECT
And these commands will trigger the corresponding cfg80211_ops hooks (.auth, .assoc, .connect) registered by the wifi driver to be called to construct the frames and then send out the frames.

Addressing ECUs directly using ELM 327 dongle and ISO 9141

I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.

Expert advisor in different trader platform

I would like to know, if I code an EA in a normal metatrader4 platform, can I reuse the .ex4 in other trading platform for example InstaTrader?
The reason is that, when I have created a new EA in InstaTrader, the EA code generated from InstaTrader is different from the one generated from metatrader4. And I couldn't find any documentation regarding to InstaTrader's EA.
Not sure anyone has encountered this before?
No. MQL is the language specifically for meta-editor which is a member of meta-trader platform.
Other trading languages may have their own scripting languages.
Metatrader4
In principle Metatrader4 uses a Metalang.exe that compiles the MQL4-source-code files into an "internally"-executable format EX4
As defined, EX4 is binary-executable on all Metatrader4 terminals.
.
WhiteLabel-ed Terminals
InstaTrader(TM) and many other *-Trader(TM)-s are so called White-Label modifications of the same MetaQuotes, Inc., software product, the [Metatrader 4 Terminal], that are just individually "skinned" in a name of the respective Broker, who has bought from the MetaQuotes, Inc. the license for a suite of [Metatrader 4 Server + Metatrader 4 Risk Management + Metatrader 4 Dealer Desk + ... ], inclusive, but not limited to, the right to re-label the client Terminal program.
Thus under most of the situations your EX4 code shall run on any other re-labeled Terminal
But...
Restrictions on binary-compatibility apply, as Metatrader4 terminals gets released in so called Builds, ( Build 432 -> Build 468 -> Build 509 -> ... -> Build 600 -> Build 624 ) and some of these have also modified the binary-code format.
Thus the EX4 code shall be hosted on a "similar" generation of the Terminal Build
Finally...
The ultimate show-stopper is the MetaQuotes, Inc., licensing policy, which makes a server-side locking to take place [Metatrader 4 Server] has a setting to reject connection requests from client Terminals in case their Build # is lesser than a treshold set on Server side.
There the SLM story ends. Forever.