How MIFARE Uses Cookies

[arturonaredo]

I have a doubt... I just faced the same error.


why are you asking for enable the nfc when the activity registration is done??

in android you can do

nfcAdapter.enableForegroundDispatch(activity.get(), pendingIntent, intentFilters, techLists);

with no risk if the app has no nfc enabled. The intents won't be delivered to the app and that's all... Why you need it? Moreover if the app is just handing Intents from android...

With this exception raising means that the registration is not successful until the nfc is on and we need to register again the activity on the result?

Cheers,
Arturo.

---

+ 0  |  - 0

[arturonaredo]

Really strange then that you guys are offering the method

 void authenticate(IKeyData var1); 

instead

authenticate(byte[] key);

.


From your own example:

    public IKeyData getKey(final String alias, final EnumKeyType keyType) {

        /**

         * MIFARE Keys are custom keys, they are not supported by SpongyCastle based keystore and

         * hence cannot be retrieved from SpongyCastle Keystore without compromising the key

         * material.

         * You can use the  method getMifareKey() to fetch Mifare Key bytes.

         */

        if (keyType == EnumKeyType.EnumMifareKey) {

            return null;

        }



        Key storedKey = mKeystoreHelper.getKey(alias);

        if (storedKey != null) {

            KeyData keyDataObj = new KeyData();

            keyDataObj.setKey(storedKey);

            return keyDataObj;

        }

        return null;

    }

You can get the content of the key:

public byte[] getKeyContent(final String alias, final EnumKeyType keyType){

        /**

         * MIFARE Keys are custom keys, they are not supported by SpongyCastle based keystore and

         * hence cannot be retrieved from SpongyCastle Keystore without compromising the key

         * material.

         * You can use the  method getMifareKey() to fetch Mifare Key bytes.

         */

        if (keyType == EnumKeyType.EnumMifareKey) {

            return null;

        }

        return mKeystoreHelper.getKey(alias).getEncoded();

    }

Without changing it to a KeyData object, like probably android is doing with the Key object from shared preferences internally.

So given that your reasons for authenticate should be the same than program3DESKey, why don't change authenticate signature with a byte array?

This is a discussion of consistency in an API at the end: https://theamiableapi.com/2011/09/14/api-design-best-practice-consistency/

Cheers,
Arturo Naredo

---

+ 0  |  - 0

[arturonaredo]

Hi support,

well, that's unfortunate... We do mocks in order to provide a solid final product and given that any developer should do it's own to test if what we pass is what is expected and the behaviour of Ultralight C and Mifare PLUS SE (both tags supported right now in our app) is correct. Given that both products are proprietary of Nxp I really encourage you guys to release a software implementation that will test every change in your API without use real cards (this will decrease dramatically the amount of time of a test cycle) and also provide developers confidence on his product showing the final user, customers, that apps using Nxp tags are reliable and usable.

From our side, as Glownet, we plan to release a simple mock of these two cards in the following month by Github where everyone could contribute to do the software development easier and faster.

Cheers,
Arturo

---

+ 0  |  - 0

[arturonaredo]

This was working successfully on Mifare SDK advanced... :(

---

+ 0  |  - 0

[arturonaredo]

Hi mirafesdk,

thank you for you answer. We have all the Ultralight C encrypted for reading. At the end we implement the counter in the customer data memory space, so as soon as we have the chance we will try again with these approach and will post you the results.

Thank you.
Arturo Naredo.

---

+ 0  |  - 0

[arturonaredo]

Is this a bug? Could you please give me some feedback?

---

+ 0  |  - 0

[Author]

Posts