DESFire EV1 Invalid MAC SecurityException

Forum / MIFARE SDK / DESFire EV1 Invalid MAC SecurityException

Tagged: ,

  • 24. July 2020 at 13:18
    I'm trying to read a Standard File from a DESFire application. Using TAPLinx, I'm able to select the application and authenticate, but when I try to readData, I get

    com.nxp.nfclib.exceptions.SecurityException: Invalid MAC


    Am I going about this the wrong way? I'm using the following API commands:

    `objDesFireEV1.selectApplication(1);
    objDesFireEV1.authenticate(1, IDESFireEV1.AuthType.Native, KeyType.THREEDES, defKeyData);
    byte[] data = objDesFireEV1.readData(0, 0, 0, IDESFireEV1.CommunicationType.MACed, len);`
    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    24. July 2020 at 13:19
    Hi Peter,

    Please check if the file permissions you have selected at creating the file really the ones you used? It seems for me that something is wrong in the reading parameters and the setting parameters.

    The TapLinx team

    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    26. July 2020 at 3:07
    I didn't create the file. I'm trying to read the contents of an existing application.

    Are there specific file permissions I should be checking for, or parameters that might cause the error I'm seeing?

    The file type shows as DataStandard, MACed communication mode, and I'm authenticating with the key number indicated by getFileSettings().getReadAccess().
    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    27. July 2020 at 9:09
    Hi Petar,

    You can have different keys for reading and writing. The error “Invalid MAC” shows that the MAC calculation, based with the key you used, is wrong. If you, for instance, authenticate with the “write key”, the authentication will succeed, but the subsequent reading will fail.

    The TapLinx team

    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    28. July 2020 at 3:58
    getReadAccess() on the file settings returns 1. This should mean that key 1 has read access, correct?

    In order to authenticate successfully, the key has to match the key number, doesn't it?
    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    28. July 2020 at 10:19
    Hi Petar,

    If the read permission is 0x01, application key #1 must be used. From the previous code snippet I see that you immediately read after the authentication. That is fine. Your code snippet looks good, I do not see an error.

    One remark: you use readData( 0, 0, 0, <comm type>, len ). Here is fileID = 0, offset = 0 and length = 0. Length = 0 means entire file. You should only read the bytes you are really need. Take in mind, reading and writing via NFC device is costly and takes performance.

    The TapLinx team

    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    10. November 2020 at 9:40
    I found out what my problem was.

    I was authenticating with KeyType.THREEDES, but the card was configured for KeyType.TWO_KEY_THREEDES.

    The key was correct, which is why authentication succeeded, but when the API proceeded with MACed communication, it would fail. Once I updated the key type during authentication, it worked as expected.
    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    23. April 2021 at 8:50
    You said, to only read amount of bytes that is needed and not all. But reading a portion of an encrypted file results to an invalid checksum exception in my desfireEV2. Therefore, I am forced to read all of the bytes.

    Secondly, I hardcode the file size because I know the value. But in case if I don't, how do I get the file size? There is none in the API that can tell me the file size.
    + 0  |  - 0

    Re: DESFire EV1 Invalid MAC SecurityException

    9. October 2021 at 9:36
    Your blog is a lot astounding. I have found effortlessly the thing I was looking. In addition, the substance quality is wonderful.
    + 0  |  - 0
Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.