Forum / MIFARE SDK / Problem with readData DesFire EV1 2k 3Des
Tagged: SOFTWARE COMPANY IN MUSCAT
-
Hi,
I have a weird problem when I read a DesFire EV1 tag (tested on several devices with several types of tags, Android TapLinx SDK 1.2)
The code is made in Kotlin, sorry about that :)
1) Write Data
val appBuilder = EV1ApplicationKeySettings.Builder()
val app = appBuilder
.setAppKeySettingsChangeable(true)
.setAppMasterKeyChangeable(true)
.setAuthenticationRequiredForFileManagement(true)
.setAuthenticationRequiredForDirectoryConfigurationData(false)
.setMaxNumberOfApplicationKeys(2)
.setKeyTypeOfApplicationKeys(KeyType.TWO_KEY_THREEDES)
.build()
dReader!!.desfireEv1.selectApplication(APP_MASTER_ID)
dReader!!.desfireEv1.createApplication(APP_USER_ID, app)
var keyVersion: Byte = 0
val keyAes = SecretKeySpec(KEY_AES128_DEFAULT, "AES")
val keyDataAes = KeyData()
dReader!!.desfireEv1.selectApplication(APP_USER_ID)
dReader!!.desfireEv1.authenticate(0, IDESFireEV1.AuthType.Native, KeyType.THREEDES, keyDataDefault)
dReader!!.desfireEv1.createFile(0, DESFireFile.StdDataFileSettings(IDESFireEV1.CommunicationType.Enciphered,
0x01.toByte(),
0x00.toByte(),
0x00.toByte(),
0x00.toByte(),
5))
dReader!!.desfireEv1.writeData(0, 0, NfcUtils.hexStringToByteArray("0000645971"))
The NfcUtils.hexStringToByteArray is a implementation found on Stackoverflow :
fun hexStringToByteArray(s: String): ByteArray {
val len = s.length
val data = ByteArray(len / 2)
var i = 0
while (i < len) {
data = ((Character.digit(s, 16) shl 4) + Character.digit(s, 16)).toByte()
i += 2
}
return data
}
When I write the bytes array, the content seems conform (writebytes.png)
But when I read later the NFC
dReader.desfireEv1.selectApplication(APP_USER_ID)
dReader.desfireEv1.authenticate(1, IDESFireEV1.AuthType.Native, KeyType.TWO_KEY_THREEDES, keyData)
val myBytes = dReader.desfireEv1.readData(0, 0, 5)
Problem: The last byte of the array can't be found (readbytes.png)
Apparently, the readData "5 bytes" only find 4 bytes.
The most weird fact it that I only have this problem when I write the String "0000645971".
When I write "0000645871" for example, I can read the 5 bytes without any problems.
+ 0 | - 0
Hi Jean-Pierre,
Sorry, but I do not understand your problem exactly. I also cannot read your code samples (never heard about this language, sorry).
What you want to say is: you read a defined amount of data bytes from a file and the returned byte array is smaller than expected? I am sure, if this is a serious problem in TapLinx, other users would gave us feedback about this issue.
If your problem is different, please concretize it with your words.
The TapLinx team
+ 0 | - 0
Hi,
the problem is exactly this one.
When I call the readData method and I ask 5 bytes, I only have 4 in return.
And I only have this problem when the chain is "0000645971" {0,0,100,89,113}
in this case, the readData(0,0,5) returns me only {0,0,100,89}
with a chain {0,0,100,88,113}, it works correctly, I have {0,0,100,88,113} in return.
+ 0 | - 0
Hi,
after further investigation,
I only have the problem when I use a communication type Enciphered and it seems to be linked to the fact that the size of my file is 5 bytes.
When I try with a 8 bytes and commmunication type Enciphered or when I try with 5 bytes and a communication type Plain, everything works correctly.
I found in the forum a similar issue (but with AES encryption). Do you know if there is the same explanation with a TWO_KEY_THREEDES encryption?
+ 0 | - 0
Hi Jean-Pierre,
Yes, in encrypted communication you must use the buffer size of the encryption method. This means this is the smallest buffer size and if you need larger buffers, it must be a multiple of the minimum buffer size.
Some crypto libraries fill the buffer for you under the hood. If you use 2K3DES or 3K3DES cipher you have to use 8 byte buffers and for AES128 16 bytes buffer size.
The TapLinx team
+ 0 | - 0
thanks for your answer :)
+ 0 | - 0
the issue has been solved few hours after my message.
Thanks for your help
+ 0 | - 0
-
AuthorPosts
Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.