Problem with readData DesFire EV1 2k 3Des

Forum / MIFARE SDK / Problem with readData DesFire EV1 2k 3Des

  • 29. August 2017 at 12:37
    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

    Re: Problem with readData DesFire EV1 2k 3Des

    29. August 2017 at 12:52
    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

    Re: Problem with readData DesFire EV1 2k 3Des

    29. August 2017 at 13:00
    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

    Re: Problem with readData DesFire EV1 2k 3Des

    29. August 2017 at 14:56
    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

    Re: Problem with readData DesFire EV1 2k 3Des

    1. September 2017 at 12:42
    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

    Re: Problem with readData DesFire EV1 2k 3Des

    1. September 2017 at 13:40
    thanks for your answer :)
    + 0  |  - 0

    Re: Problem with readData DesFire EV1 2k 3Des

    1. September 2017 at 13:43
    the issue has been solved few hours after my message.
    Thanks for your help

    + 0  |  - 0
Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.