I'm working with smart cards and APDU commands.
I am trying to digitally sign a hash with the private key inside my card.
Following some tutorials, I am executing the following script but the last one gives me an error.
00 20 00 81 06 3x 3x 3x 3x 3x 3x --VERIFY response: 9000
00 A4 04 00 XX xx xx xx xx xx xx..... --SELECT APP response: 9000
00 22 41 B6 06 80 01 8A 84 01 81 --SECURITY ENVIRONMENT response: 9000
00 2A 9E 9A XX xx xx xx xx xx xx..... --SIGN response: 6a88
In the last command, the expected response would be: HASH_SIGNED + 9000. But it is responding: 6a88.
Could someone help me, what may be wrong or what am I doing wrong?
Related
I have a clean Kona112 Javacard and I'm going to a put a Receipt key into it and then I want to delete it from the card or replace its value.
Step 1: I tried to create a new key on the card with Key Version == 0x71 (Quoted from GP UICC Configuration v1.0.1: "Key Version number '71' with Key Identifier '01' is reserved for the Receipt Key, which is a DES key"):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 B5 75 C3 8D 89 DC F9 B1 74 CC 1E 93 C4 45 C8 2C 03 CD 80 0F EC EA 8D 6F 8F BF 7D D0 // PUT KEY
<-- 6A 80
==> Quoted from GP UICC Configuration v1.0.1: "6A80 = ISO compliant standard status word for Algorithm not supported"
Step 2: As I received "Algorithm not supported" error, I enabled Delegated Management on my card and retried step #1:
[Select ISD]
[Successful Mutual Authentication]
[Proprietary APDU command to enable Delegated Management]
--> 84 D8 00 01 1F 71 80 10 1A F6 96 45 2A ED 66 86 75 DF FC 8B 59 55 6D 0B 03 CD 80 0F 87 03 E4 1A 8D AB 90 EC
<-- 71 CD 80 0F 90 00
Good! I successfully put the Receipt key in the card.
Step 3: Now, I want to delete it:
[Select ISD]
[Successful Mutual Authentication]
--> 80 E4 00 00 06 D0 01 01 D2 01 71 // Delete APDU Command to delete a key with Key ID = 01 and Key Version = 71
<-- 6A 80
As you see above, I received 6A 80 error status words. It is mentioned in the answer of my other question (and also in GP UICC Configuration v1.0.1) that the Key Deletion feature is optional.
So in step #4 I tried to replace the key with another value.
Step 4: I changed P1 in PUT Key APDU command from 0x00 (create key) to 0x71 (overwrite):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 71 01 1F 71 80 10 E9 06 6B 8E D8 05 50 34 D5 A7 71 3B 81 CB BE 7A 03 CD 80 0F 91 0D BC E9 96 25 7E 89
<-- 6A 88
==> Quoted from GP UICC Configuration v1.0.1: "6A88 = Referenced data not found"
Well, that's weird, I received "Referenced data not found". So I tried the PUT Key command with P1 = 0X00 (Create Key) again:
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 31 35 5C 0C E3 27 FD D5 8B 6B AE 37 56 CA 0D F2 03 CD 80 0F 0B EB 16 CF FF CE 4C 09
<-- 69 85 // Conditions of used not satisfied.
Well, I tried both cases of step #3 (P1 = 0x00 and P1 = 0x71) with disabled Delegated Management too, but nothing changed and I respectively received 0x6A80 and 0x6A88.
What's wrong? How can I fix the delete or modify this key?
Note that I tried all the steps in secure channel with SecurityLevel = 0x03 too. Nothing changed.
Update:
I tried to list the available keys in the card using GET DATA APDU command with Key Info Template tag, but I only can see ISD ENC, MAC and KEK keys in the APDU Response (For both DM enabled and DM Disabled.
--> 80 CA 00 E0 00
<-- E0 12 C0 04 01 01 80 10 C0 04 02 01 80 10 C0 04 03 01 80 10 90 00
One idea: The receipt key (and you also have to store a token key) might be linked to a application security domain. Select the Security Domain with Token Verification privilege and the Security Domain with Receipt Generation
privilege, maybe they are different from the ISD. I assume also that during [Proprietary APDU command to enable Delegated Management] a new application security domain (ASP) was created. Try the select these new security domains and list there all the keys using the key template flag and execute then your PUT KEY operations against one of these security domains. GET STATUSis the command to be used for listing the SDs. All the existing OS tools like GPShell and GlobalPlatformPro can do this.
I have following scenarios below. I am trying to find the reason why GENERATE APPLICATION CRYPTOGRAM gives me response 6985.
Good sample:
GENERATE APPLICATION CRYPTOGRAM - using in terminal same country code and currency code as on card gives me correct APPLICATION CRYPTOGRAM RESPONSE.
GENERATE APPLICATION CRYPTOGRAM - GOOD
Generate AC Using CDOL 1
Terminal Supplied Data
Amount, Authorised - 000000000201
Amount, Other - 000000000000
Terminal Country Code - 0840 - United States
Terminal Verification Results - 00 00 00 00 00
Transaction Currency Code - 0840 - US Dollar
Transaction Date - 20 07 01
Transaction Type - 00 - Goods and Services
Unpredictable Number - 30 90 1B 6A
Terminal Type - 22 - Attended, offline with online capability. Operated by Merchant
Data Authentication Code - 00 00
ICC Dynamic Number - 00 00 00 00 00 00 00 00
CVM Results - 00 00 00
<snd> (049) 80 AE 40 00 2B 00 00 00 00 02 01 00 00 00 00 00
00 08 40 00 00 00 00 00 08 40 20 07 01 00 30 90
1B 6A 22 00 00 00 00 00 00 00 00 00 00 00 00 00
00
<rcv> (045) 77 29 9F 27 01 XX 9F 36 02 XX XX 9F 26 08 XX XX
XX XX XX XX XX XX 9F 10 12 XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX 90 00
Bad sample:
GENERATE APPLICATION CRYPTOGRAM - using in terminal with different country code and currency code on card gives me response 6985, that's the only difference I could observe. The PDOL is not personalized on the card.
SELECT
Selecting Application A0000000041010 - MasterCard
<snd> (013) 00 A4 04 00 07 A0 00 00 00 04 10 10 00
<rcv> (063) 6F 3B 84 07 A0 00 00 00 04 10 10 A5 30 50 10 4D
61 73 74 65 72 63 61 72 64 20 44 65 62 69 74 87
01 01 5F 2D 02 65 6E 9F 11 01 01 BF 0C 0F 9F 4D
02 0B 0A 5F 55 02 55 53 42 03 XX XX XX 90 00
84 - DF Name - A0 00 00 00 04 10 10
A5 - FCI Proprietary Template
50 - Application Label - Mastercard Debit
87 - Application Priority Indicator - 01
5F2D - Language Preference - en
9F11 - Issuer Code Table Index - 01
BF0C - FCI Issuer Discretionary Data
9F4D - Log Entry - 0B 0A
5F55 - Issuer Country Code (Alpha 2) - "US"
42 - Issuer Identifier Number - XX XX XX
GPO
Get Processing Options
<snd> (008) 80 A8 00 00 02 83 00 00
<rcv> (018) 77 0E 82 02 18 00 94 08 08 01 01 00 10 01 01 00
90 00
82 - Application Interchange Profile - 18 00
94 - Application File Locator - 08 01 01 00 10 01 01 00
- File Locator 1 - 1 1 1 0
- File Locator 2 - 2 1 1 0
GENERATE APPLICATION CRYPTOGRAM
Generate AC Using CDOL 1
Terminal Supplied Data
Amount, Authorised - 000000000201
Amount, Other - 000000000000
Terminal Country Code - 0826 - United Kingdom
Terminal Verification Results - 00 00 00 00 00
Transaction Currency Code - 0826 - Pound Sterling
Transaction Date - 20 07 01
Transaction Type - 00 - Goods and Services
Unpredictable Number - 30 90 1B 6A
Terminal Type - 22 - Attended, offline with online capability. Operated by Merchant
Data Authentication Code - 00 00
ICC Dynamic Number - 00 00 00 00 00 00 00 00
CVM Results - 00 00 00
<snd> (049) 80 AE 40 00 2B 00 00 00 00 02 01 00 00 00 00 00
00 08 26 00 00 00 00 00 08 26 20 07 01 00 30 90
1B 6A 22 00 00 00 00 00 00 00 00 00 00 00 00 00
00
<rcv> (002) 69 85
Thank you
I'm working to get useful data from a VISA (such as PAN, expiry date...) credit card using a list of AIDs I got stuck.
I have been able to access to all the data manually. Using the next tutorial: http://www.openscdp.org/scripts/tutorial/emv/reademv.html
>>00 A4 04 00 07 A0 00 00 00 03 10 10 00
In ASCII:
<<o<EM>„<BEL> <0><0><0><ETX><DLE><DLE>¥<SO>P<EOT>VISA¿<FF><ENQ>ŸM<STX><VT><LF><0>
In Hexadecimal:
<<6F 19 84 07 A0 00 00 00 03 10 10 A5 0E 50 04 56 49 53 41 BF 0C 05 9F 4D 02 0B 0A 90 00
After that I used:
>>33 00 B2 01 0C 00 //sfi1, rec1
...
...
>>33 00 B2 10 FC 00 //sfi31, rec16
I continued with the tutorial and learned that the proper way to obtain the data was using GPO (Get Processing Options) command. And tried that next:
>>80 A8 00 00 0D 83 0B 00 00 00 00 00 00 00 00 00 00 00 00 // pdo = 83 0B 00 00 00 00 00 00 00 00 00 00 00 which suposse to be the correct one for VISA.
<< 69 85
So the condition of use is not satisfied.
>> 80 A8 00 00 02 83 00 00 //pdo= 83 00 that should work with every non visa card
<< 80 0E 3C 00 08 01 01 00 10 01 04 00 18 01 03 01 90 00
If this response is correct and it looks quite well for me as it starts by 80 and ends by 90 00, I am not able to identify AFL which I think that would make me possible to determine the PAN, expiry date... Can somebody help me?
The FCI that you received in response to the select command (00 A4 0400 07 A0000000031010 00) decodes to
6F 19 (File Control Information (FCI) Template)
84 07 (Dedicated File (DF) Name)
A0000000031010
A5 0E (File Control Information (FCI) Proprietary Template)
50 04 (Application Label)
56495341 ("VISA")
BF0C 05 (File Control Information (FCI) Issuer Discretionary Data)
9F4D 02 (Log Entry)
0B0A (SFI = 11; # of records = 10)
This FCI does not include any PDOL (processing options data list). Consequently, you need to assume a default value for the PDOL (which is an empty list for your card type). Consequently, the PDOL-related data field in the GET PROCESSING OPTIONS command must be empty:
83 00
Where 0x83 is the tag for PDOL-related data and 0x00 is a length of zero bytes.
Thus, the correct GPO command is (as you already found out):
80 A8 0000 02 8300 00
You got the response
800E3C00080101001001040018010301 9000
This decodes to
80 0E (Response Message Template Format 1)
3C00 (Application Interchange Profile)
08010100 10010400 18010301 (Application File Locator)
Consequently, the Application File Locator contains the following three entries:
08010100: SFI = 1, first record = 1, last record = 1, records involved in offline data authentication = 0
10010400: SFI = 2, first record = 1, last record = 4, records involved in offline data authentication = 0
18010301: SFI = 3, first record = 1, last record = 3, records involved in offline data authentication = 1
Consequently, you can read those record with the READ RECORD commands:
00 B2 010C 00
00 B2 0114 00
00 B2 0214 00
00 B2 0314 00
00 B2 0414 00
00 B2 011C 00
00 B2 021C 00
00 B2 031C 00
I would like to echo an array of bytes from the linux terminal to serial port. Have already seen this Sending bytes to serial port from UNIX command line? and from that deduced the command will be something like the following:
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > /dev/ttyUSB0
To debug the ideia I redirected it to a file with
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > file.raw
and checked the file with hexedit. But so I've found that ASCII values were been written instead.
In the end I expect the following in the file:
9c 86 84 a4 62 40 00 a0 b2 66 8a 84 40 00 03 f0 03 01 00 00 00 04 8a b0 c0
For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?
Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)