Set own authentication keys MiFare Classic with APDU C# - rfid

I'm using the SMARTCARD API from CardWerk.
How can I change the default key ((byte)0xFF, (byte)0xFF, (byte)0xFF, (byte)0xFF, (byte)0xFF, (byte)0xFF) using an APDU?
The APDU consits of a CLASS, an INSTRUCTION, P1, P2.
I have been reading documentation but I'm unable to find what parameters do I need to change the actual key to a new one.

The process for changing the keys of a MIFARE Classic card is like this:
Authenticate to the secor for which you want to change the key.
Read the sector trailer using normal read operation (or generate a new sector trailer containing the access bytes you want). The sector trailer is the last block of the sector (i.e. for MF Classic 1K, block 3 of each sector).
Fill the sector trailer with the new key(s). Note that you won't be able to read the current keys in step 2, so you have to fill in key A and key B (if it exists) even if you want them to stay the same as before!)
Write the sector trailer using normal write operation.
Authenticate to another sector (if you want the change to take effect immediately).
The sector trailer is formatted like this:
xx xx xx xx xx xx zz zz zz gg yy yy yy yy yy yy
Where xx xx xx xx xx xx is key A, yy yy yy yy yy yy is key B and zz zz zz are the access bytes that enforce key-based access permissions. gg is a general-purpose byte with no specific meaning unless you use a MIFARE application directory or NXP's NDEF mapping for using MIFARE Classic as NFC tag).
Be warned that setting the access bytes to an invalid value will render the card inaccessible!
An example sector trailer could look like this:
FF FF FF FF FF FF 78 77 88 00 FF FF FF FF FF FF
The access conditions meaning that you can read with key A and read/write with key B.
As MIFARE Classic cards do not speak APDU, it's difficult to give you a ready-made APDU command for this. (MIFARE Classic cards are contactless memory cards and use their own proprietary contactless protocol and PC/SC-compliant smartcard readers usually only map these proprietary memory access commands to APDUs.)
However, if your reader supports PC/SC 2.01 commands for storage cards, commands could look like this:
Load a key xxxxxxxxxxxx to key slot 0 (depending on your reader you might need to encode a different slot numer in P2; remember to adapt the authenticate command in that case):
FF 82 2000 06 xxxxxxxxxxxx
Authenticate sector 0 using that key as key A:
FF 86 0000 05 01 0000 60 00
Or authenticate sector 0 using that key as key B:
FF 86 0000 05 01 0000 61 00
Write new sector trailer for sector 0 (in block 3):
FF D6 0003 10 xxxxxxxxxxxx zzzzzz gg yyyyyyyyyyyy

Related

Access a SmartCard iso14443A with Node.js

I´m trying to access the Information on a Mifare Smartcard(iso14443A) over a Omnikey 5321 CL reader.
I tried to use the smartcard lib, but it uses an other iso standard.
For accessing the Card I have to set a Application ID ( 3x hex), a key (32 int), keyid (hex).
You can still use smartcard lib, but you have to configure the reader to use the MIFARE mode instead of the T-CL variant of 14443 protocol.
If I remember corectly, the Omnikey workbench provides a graphical configuration tool for that purpose.
I strongly recommend to study Omnikey contactless smart card readers developer guide, especially the section MIFARE emulation mode, for serious work.
(I have no idea, what a one byte Application ID means in Mifare context, and what value 3x is supposed to represent.)
I am busy with similar process, however after searching I found this example:
https://github.com/santigimeno/node-pcsclite
EDIT
In fact I actually got this one working
https://github.com/pokusew/nfc-pcsc
It returns the following:
ACS ACR122 0 card detected {
atr: <Buffer 3b 8f 80 01 80 4f 0c a0 00 00 03 06 03 00 01 00 00 00 00 6a>,
standard: 'TAG_ISO_14443_3',
type: 'TAG_ISO_14443_3',
uid: '767aec7e'
}

(Smart Card) APDU Command to sign

I'm developing an application that require a client authentication to a server using a smart card.
As a guide, i'm tracing a normal web authentication with a browser and i've seen that the SSL/TLS packet containing the "Certificate Verify" structure is created using the signing session of the card.
Analizing the CCID-APDU packet sent to the card reader i've seen this dump:
6f 05 01 00 00 00 41 00 01 00 00 2a 80 86 00 01 01 00 00 01 ff ff ........
The answer of this command is actually the content sent to the 'Certificate Verify' SSL/TLS structure.
The strange thing is that the APDU command sent is
00 2a 80 86 00
Looking at the APDU documentation this is a "PSO: DECIPHER" command but shouldn't it be a signature command? (00 2A 9E 9A xx)
Would anyone be able to clarify this behavior?
Tnx
PSO DECIPHER shares with signature generation that it applies the private key. It is significantly simpler, since it is restricted to one data block, i. e. the command data field of the APDU. PSO CDS for Compute Digital Signature has lots of additional complications like chaining (data split to several commands), hashing (with various algorithms to use), padding (with various padding schemes) to ensure correct data length etc.
So it seems, that your analyzed solution is optimized for the specific scenario required, and as many optimizations clarity is somewhat reduced as side effect.

APDU command change IMSI SIM CARD

I am trying to use UPDATE BINARY command using APDU command for modify IMSI code, but The response is 98 04.
A0 A4 00 00 02 3F 00 -> SELECT MF
A0 A4 00 00 02 7F 20 -> Select DF_GSM
A0 A4 00 00 02 6F 07 ->Select EF_IMSI
A0 D6 00 00 09 [08 79 03 30 60 00 61 33 23] -> UPDATE IMSI FOR RANDOM NUMBER
when doing this I get the following response 98 04 and it is not modified.
According to the documentation The response 98 04 can mean the following:
access condition not fulfilled
unsuccessful CHV verification, at least one attempt left
unsuccessful UNBLOCK CHV verification, at least one attempt left
authentication failed
How I can change IMSI?
Thank you.
From 3GPP-TS-11.011 - You have to verify ADM first in order to update EF_IMSI. See link. Typically only the network has the "password". Otherwise anyone with the password can impersonate the identity of someone else's SIM card.
EF_IMSI Update Conditions
In order to update IMSI file on SIM , UPDATE command header and data part should be generated according GSM 03.48 specification. For the SIM file structure 31.102 is the specification.
Command header parameters should be obtained from SIM vendor. Minimum security Level parameter will definitely enforce encryption and cryptographic cHecksum usage for securing the command data, because real SIM card card manager expects MSL parameters something like that 0x25, so KiC and KiD key values are required.
You need first to Verify CHV (PIN1 for IMSI).
Use the following APDU and replace your PIN1 value.
-> A0 20 00 01 08 31 32 33 34 FF FF FF FF
<- 90 00
Caution: If you use wrong PIN value, it will be disabled after 3 times.

generate AC cryptogram manually

I am trying to generate AC manually, I have a tool to generate AC but I want to generate it by my own to understand the algorithm for the same.
My calculation is fine for Discover card but it is failing for MasterCard. As per my understanding, data used to generate AC is depend on Tag 8C - CDOL1 which we provide to card with Gen AC command + AIP + ATC.
AIP and ATC - accessed internally by ICC.
Data used to generate AC is:-
data part of Gen AC command + value of tag 82 + value of tag 9f36 + 80 + optional 00 to make it multiple of 8.
this is my logic ,it might be I am using wrong data to calculate A.C that's why getting different result from my test tool.
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 - 15 04 28
Transaction Type - 00 - Goods and Services
Unpredictable Number - 30 90 1B 6A
Terminal Type - 23 - Attended, offline only. Operated by Merchant
Data Authentication Code - 00 00
ICC Dynamic Number - 1E AB C1 26 F8 54 99 76
CVM Results - 00 00 00
Gen AC Using CDOL1
80 AE 40 00 2B 0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F8549976000000
this command is returning 9F26.
data i used for calcatation is:-
0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F85499760000003800000180 [ data is multiple of 8]
Where 3800 is AIP 0001 is ATC and 80 for Padding [ Padding method 2 EMV] This is my logic, Is any body tell me where I should focus more to generate same AC as my tool generated.
MasterCard Application Cryptogram (AC) generation is more complicated than other card schemes.
Card can use different ICC Session Key Derivation (SKD) methods:
MasterCard Proprietary SKD, where involved Application Transaction Counter (ATC) and Unpredictable Number (UN);
EMV2000 Method, where involved only ATC - see EMV 4.0, Book 2;
EMV Common Session Key (CSK) Method, where involved only ATC - see EMV 4.2, Book 2;
Data Objects (DO) can be with different sets of additional or modified values:
Card Verification Results (CVR) can be 6 or 4 bytes.
The offline counters from Issuer Application Data (IAD) can be included.
Last online ATC value can be included.
The used method and data variant can be detected by Cryptogram Version Number (CVN) and Application Control bits. CVN is sub-field of IAD tag 0x9F10 .
The detailed information are proprietary and available for the MasterCard members.
For deep learning about it take a look into "M/Chip Card Application Cryptographic Algorithms" and M/Chip Card Application references.

Understanding the ZMODEM protocol

I need to include basic file-sending and file-receiving routines in my program, and it needs to be through the ZMODEM protocol. The problem is that I'm having trouble understanding the spec.
For reference, here is the specification.
The spec doesn't define the various constants, so here's a header file from Google.
It seems to me like there are a lot of important things left undefined in that document:
It constantly refers to ZDLE-encoding, but what is it? When exactly do I use it, and when don't I use it?
After a ZFILE data frame, the file's metadata (filename, modify date, size, etc.) are transferred. This is followed by a ZCRCW block and then a block whose type is undefined according to the spec. The ZCRCW block allegedly contains a 16-bit CRC, but the spec doesn't define on what data the CRC is computed.
It doesn't define the CRC polynomial it uses. I found out by chance that the CRC32 poly is the standard CRC32, but I've had no such luck with the CRC16 poly. Nevermind, I found it through trial and error. The CRC16 poly is 0x1021.
I've looked around for reference code, but all I can find are unreadable, undocumented C files from the early 90s. I've also found this set of documents from the MSDN, but it's painfully vague and contradictory to tests that I've run: http://msdn.microsoft.com/en-us/library/ms817878.aspx (you may need to view that through Google's cache)
To illustrate my difficulties, here is a simple example. I've created a plaintext file on the server containing "Hello world!", and it's called helloworld.txt.
I initiate the transfer from the server with the following command:
sx --zmodem helloworld.txt
This prompts the server to send the following ZRQINIT frame:
2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30 **.B000000000000
30 30 0D 8A 11 00.Š.
Three issues with this:
Are the padding bytes (0x2A) arbitrary? Why are there two here, but in other instances there's only one, and sometimes none?
The spec doesn't mention the [CR] [LF] [XON] at the end, but the MSDN article does. Why is it there?
Why does the [LF] have bit 0x80 set?
After this, the client needs to send a ZRINIT frame. I got this from the MSDN article:
2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65 **.B0100000023be
35 30 0D 8A 50.Š
In addition to the [LF] 0x80 flag issue, I have two more issues:
Why isn't [XON] included this time?
Is the CRC calculated on the binary data or the ASCII hex data? If it's on the binary data I get 0x197C, and if it's on the ASCII hex data I get 0xF775; neither of these are what's actually in the frame (0xBE50). (Solved; it follows whichever mode you're using. If you're in BIN or BIN32 mode, it's the CRC of the binary data. If you're in ASCII hex mode, it's the CRC of what's represented by the ASCII hex characters.)
The server responds with a ZFILE frame:
2A 18 43 04 00 00 00 00 DD 51 A2 33 *.C.....ÝQ¢3
OK. This one makes sense. If I calculate the CRC32 of [04 00 00 00 00], I indeed get 0x33A251DD. But now we don't have ANY [CR] [LF] [XON] at the end. Why is this?
Immediately after this frame, the server also sends the file's metadata:
68 65 6C 6C 6F 77 6F 72 6C 64 2E 74 78 74 00 31 helloworld.txt.1
33 20 32 34 30 20 31 30 30 36 34 34 20 30 20 31 3 240 100644 0 1
20 31 33 00 18 6B 18 50 D3 0F F1 11 13..k.PÓ.ñ.
This doesn't even have a header, it just jumps straight to the data. OK, I can live with that. However:
We have our first mysterious ZCRCW frame: [18 6B]. How long is this frame? Where is the CRC data, and is it CRC16 or CRC32? It's not defined anywhere in the spec.
The MSDN article specifies that the [18 6B] should be followed by [00], but it isn't.
Then we have a frame with an undefined type: [18 50 D3 0F F1 11]. Is this a separate frame or is it part of ZCRCW?
The client needs to respond with a ZRPOS frame, again taken from the MSDN article:
2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38 **.B0900000000a8
37 63 0D 8A 7c.Š
Same issues as with the ZRINIT frame: the CRC is wrong, the [LF] has bit 0x80 set, and there's no [XON].
The server responds with a ZDATA frame:
2A 18 43 0A 00 00 00 00 BC EF 92 8C *.C.....¼ï’Œ
Same issues as ZFILE: the CRC is all fine, but where's the [CR] [LF] [XON]?
After this, the server sends the file's payload. Since this is a short example, it fits in one block (max size is 1024):
48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A Hello world!.
From what the article seems to mention, payloads are escaped with [ZDLE]. So how do I transmit a payload byte that happens to match the value of [ZDLE]? Are there any other values like this?
The server ends with these frames:
18 68 05 DE 02 18 D0 .h.Þ..Ð
2A 18 43 0B 0D 00 00 00 D1 1E 98 43 *.C.....Ñ.˜C
I'm completely lost on the first one. The second makes as much sense as the ZRINIT and ZDATA frames.
My buddy wonders if you are implementing a time
machine.
I don't know that I can answer all of your questions -- I've never
actually had to implement zmodem myself -- but here are few answers:
From what the article seems to mention, payloads are escaped with
[ZDLE]. So how do I transmit a payload byte that happens to match the
value of [ZDLE]? Are there any other values like this?
This is explicitly addressed in the document you linked to at the
beginning of your questions, which says:
The ZDLE character is special. ZDLE represents a control sequence
of some sort. If a ZDLE character appears in binary data, it is
prefixed with ZDLE, then sent as ZDLEE.
It constantly refers to ZDLE-encoding, but what is it? When exactly
do I use it, and when don't I use it?
In the Old Days, certain "control characters" were used to control the
communication channel (hence the name). For example, sending XON/XOFF
characters might pause the transmission. ZDLE is used to escape
characters that may be problematic. According to the spec, these are
the characters that are escaped by default:
ZMODEM software escapes ZDLE, 020, 0220, 021, 0221, 023, and 0223.
If preceded by 0100 or 0300 (#), 015 and 0215 are also escaped to
protect the Telenet command escape CR-#-CR. The receiver ignores
021, 0221, 023, and 0223 characters in the data stream.
I've looked around for reference code, but all I can find are
unreadable, undocumented C files from the early 90s.
Does this include the code for the lrzsz package? This is still
widely available on most Linux distributions (and surprisingly handy
for transmitting files over an established ssh connection).
There are a number of other implementations out there, including
several in software listed on freecode, including qodem,
syncterm, MBSE, and others. I believe the syncterm
implementation is written as library that may be reasonable easy
to use from your own code (but I'm not certain).
You may find additional code if you poke around older collections of
MS-DOS software.
I can't blame you. The user manual is not organized in a user friendly way
Are the padding bytes (0x2A) arbitrary?
No, from page 14,15:
A binary header begins with the sequence ZPAD, ZDLE, ZBIN.
A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX.
.
The spec doesn't mention the [CR] [LF] [XON] at the end, but the MSDN article does. Why is it there?
Page 15
* * ZDLE B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON
.
Why does the [LF] have bit 0x80 set?
Not sure. From Tera term I got both control characters XORed with 0x80 (8D 8A 11)
We have our first mysterious ZCRCW frame: [18 6B]. How long is this frame? Where is the CRC data, and is it CRC16 or CRC32? It's not defined anywhere in the spec.
The ZCRCW is not a header or a frame type, it's more like a footer that tells the receiver what to expect next. In this case it's the footer of the data subpacket containing the file name. It's going to be a 32 bit checksum because you're using a "C" type binary header.
ZDLE C TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CRC-3 CRC-4
.
Then we have a frame with an undefined type: [18 50 D3 0F F1 11]. Is this a separate frame or is it part of ZCRCW?
That's the CRC for the ZCRCW data subpacket. It's 5 bytes because the first one is 0x10, a control character that needs to be ZDLE escaped. I'm not sure what 0x11 is.
and there's no [XON].
XON is just for Hex headers. You don't use it for a binary header.
ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2
.
So how do I transmit a payload byte that happens to match the value of [ZDLE]?
18 58 (AKA ZDLEE)
18 68 05 DE 02 18 D0
That's the footer of the data subframe. The next 5 bytes are the CRC (last byte is ZDLE encoded)
The ZDLE + ZBIN (0x18 0x41) means the frame is CRC-CCITT(XMODEM 16) with Binary Data.
ZDLE + ZHEX (0x18 0x42) means CRC-CCITT(XMODEM 16) with HEX data.
The HEX data is tricky, since at first some people don't understand it. Every two bytes, the ASCII chars represent one byte in binary. For example, 0x30 0x45 0x41 0x32 means 0x30 0x45, 0x41 0x32, or in ASCII 0 E A 2, then 0x0E, 0xA2. They expand the binary two nibbles to a ASCII representation. I found in several dataloggers that some devices use lower case to represent A~F (a~f) in HEX, it doesn't matter, but on those, you will not find 0x30 0x45 0x41 0x32 (0EA2) but 0x30 0x65 0x61 0x32 (0ea2), it doesn't change a thing, just make it a little bit confuse at first.
And yes, the CRC16 for ZBIN or ZHEX is CRC-CCITT(XMODEM).
The ZDLE ZBIN32 (0x18 0x43) or ZDLE ZBINR32 (0x18 0x44) use CRC-32 calculation.
Noticing that the ZDLE and the following byte are excluded in the CRC calculation.
I am digging into the ZMODEM since I need to "talk" with some Elevators Door Boards, to program a new set of parameters at once, instead using their software to change attribute by attribute. This "talk" could be on the bench instead sitting over the elevator car roof with a notebook. Those boards talk ZMODEM, but as I don't have the packets format they expect, the board still rejecting my file transfer. The boards send 0x2a 0x2A 0x18 0x42 0x30 0x31 0x30 (x6) + crc, the Tera Terminal transfering the file in ZMODEM send to the board 0x2A 0x2A 0x18 0x42 0x30 0x30 ... + CRC, I don't know why this 00 or 01 after the 0x4B means. The PC send this and the filename and some file attributes. The board after few seconds answer with "No File received"...

Resources