Hallo Martin,
it seems you are right. Obviously, my tests were too superficial.
I tested with an Omnikey 5321, but that reader automatically activated
the SMX up to the ISO 14443-4 layer, so it was not possible to transmit
any MIFARE Commands.
I, therefore, switched to an ACR122U. I followed the instructions in
that reader's manual to stop activation after ISO 14443-3 (the layer
were MIFARE Classic kicks in). This seemed to work, but regardless of
what commands I sent to the reader my program told me that the commands
were successful. Yet, when I tried to read back any previously written
data it did not work.
It took me a while to figure out what was going wrong: I misinterpreted
the steps required to stop ISO 14443-4 activation.
I can now confirm that reading & writing the MIFARE Classic area of the
SmartMX works with the default keys (0xffffffffffff). (Tested with a
properly initialized ACR122U and an NXP Pegoda reader.)
Actually, I'm still a bit surprised that the default keys were used
here. In fact I would have expected that the MIFARE area was locked with
some non-standard keys to be protected against modification by anyone
except Google (or whoever will get access to te rest of the secure element).
So now we would only need to find a way to access the MIFARE area from
within an application on the phone.
I'm currently testing with a modified version of the 2.3.4 firmware. But
as with the smart card readers, the SmartMX is automatically activated
up to the ISO 14443-4/APDU layer. So far I was unable to use any MIFARE
Classic commands to access the secure element.
br
Michael
On 20.05.2011 13:32 Martin wrote:
>
> Hello Michael,
>
> here are the information I promised you yesterday.
>
> Reader: Omnikey 55x3
> Software: HID Reader Utility Version 4.0.0.0
>
> Key: FFFFFFFFFFFF it works for each sector.
>
> This is what we found in the api:
>
> // The well-known default MIFARE read key. All keys are set to this at
> the factory.
> // Using this key will effectively make the payload in the sector
> public.
>
> public static final byte[] KEY_DEFAULT =
>
> {(byte)0xFF,(byte)0xFF,(byte)0xFF,(byte)0xFF,
> (byte)0xFF,(byte)0xFF};
>
> I checked the UID of the SecureElement, which I can get by calling the
> getSecureElementUid() of the NfcSecureElement class via reflection.
> And I also checked the sector 00 block 00 of the emulated MiFare card
> with our external NFC reader to get the UID. They match!
>
> Do you think it is possible to read/write data with APDU commands?
> There is a hidden method in the NfcSecureElement class called
> exchangeAPDU.
> public byte [] exchangeAPDU(int handle,byte [] data){...}
>
> I have tried some commands, which I found on page eleven at the
> following pdf document:
>
> http://www.nfc-reader.com/NFC-smart-card-reader/ACR122-API-Manual/API_ACR122.pdf
>
> But I always get back 6E 00.
>
> Best wishes!
>
> Martin
>
>
> On 19 Mai, 20:18, Michael Roland <[email protected]> wrote:
>> Hallo Martin,
>>
>>> After enabling the card emulation mode on the Nexus S, I am able to
>>> read and write data to the emulated MiFare Classic 4k card by an
>>> external NFC reader. I would like to do that within an android app.
>>
>> Have you verified that you actually wrote data to the MIFARE Classic? I
>> really doubt that you did. What MIFARE keys did you use? In my tests
>> authentication passed regardless of the keys I used. In fact every
>> command seemed to return successfully, but in fact no data was ever
>> written to the card.
>>
>>> You have
>>> spoken about the access keys, but aren't they the same for internal
>>> and external access?
>>
>> Yes, they would be the same for internal and external access.
>>
>> br,
>> Michael
>>
>>
>>
>>
>>
>>
>>
>>> On 19 Mai, 00:59, Michael Roland <[email protected]> wrote:
>>>> Hallo,
>>
>>>>> I more or less understand how to do it but I don't understand if after
>>>>> is possible to build application on card emulation.
>>
>>>> Regarding the internalsecureelement(SmartMX): No. Even if you
>>>> activate this chip as thesecureelement, you could only use its UID for
>>>> your application. To edit data on it/install applications into it you
>>>> would need to have the access keys for thatsecureelement.
>>
>>>> Regarding an externalsecureelementon the UICC ("SIM" card): Partly
>>>> yes. You can activate an SWP-UICC assecureelement. But access is
>>>> limited to external readers for the moment. Until now, there is no known
>>>> way to get access to application on the UICC from a phone application.
>>
>>>>> Moreover some of you speak about authentication, and about a password
>>>>> that is not possible to have? (What are you talking about when you
>>>>> speak about this stuff).
>>
>>>> The SmartMX in the Nexus S contains a JavaCard operating system that is
>>>> compliant to GlobalPlatform. GlobalPlatform defines methods to manage
>>>> multiple applications on this JavaCard. A central component of this card
>>>> management is the Card Manager, which itself is one application on
>>>> thesecureelement. The card manager provides an interface to load, install,
>>>> ... delete applications on thesecureelement. Additionally it controls
>>>> access to these methods. To establish asecurechannel with the card
>>>> manager (i.e. a connection that provides authenticity, integrity and
>>>> possibly confidentiality) both, the entity that wants to manage the card
>>>> and the card manager need to know one or more shared secrets, the
>>>> authentication keys.
>>
>>>>> Anyway some news aboutNFCcard emulation
>>>>> [nearfieldcommunicationworld]
>>>>> it seems that Google dev will not give use api about that in the next
>>>>> future.
>>
>>>> Still there is some developments towards card emulation going on
>>>> (cf.http://www.nfctimes.com/news/android-card-emulation-expected-despite-...
>>>> )
>>
>>>>> Moreover, what does it mean "And if you improperly authenticate
>>>>> yourself a certain number of times, there aresecureelements out
>>>>> there that will physically destroy themselves and can never be
>>>>> recovered"? Is related to the password of my previous questions?
>>
>>>> While the card manager is protected by access keys, there still exist
>>>> some methods to find such keys. One of these methods would be brute
>>>> forces (i.e. trying each possible key value). While such methods are
>>>> usually very inefficient (if the key has an appropriate length) there
>>>> might be some methods that could significantly speed up this process. As
>>>> a safety mechanism the card manager usually implements an additional
>>>> protection against such an attack: After ten consecutive authentication
>>>> failures, the card manager locks itself and refuses any further
>>>> commands. (Other applications that were previously installed on that
>>>> card will continue to function as usual.) Once this lockdown has
>>>> happened, there is *NO* way of reversing this. THerefore, once in
>>>> lockdown no applications can be installed on, removed from, ...
>>>> thesecureelement.
>>
>>>> br
>>>> Michael
>>
>>>>> On May 16, 3:48 pm, Goo_Goo <[email protected]> wrote:
>>>>>> Could someone please post the the image withcardemulationenabled
>>>>>> for Nexus S?
>>
>>>>>> On May 13, 5:08 am, Markus <[email protected]> wrote:
>>
>>>>>>> mtk
>>>>>>> you wrote after call
>>>>>>> phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeWired,nfc_jni_se_set_mode_callb
>>>>>>> ack,
>>>>>>> (void *)nat);
>>>>>>> your nexus s was incardemulation
>>
>>>>>>> I called it with mode default
>>>>>>> phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeDefault,nfc_jni_se_set_mode_cal
>>>>>>> lback,
>>>>>>> (void *)nat);
>>>>>>> and get following log
>>>>>>> 5-12 22:08:54.421: DEBUG/NFCJNI(303):NFCcapabilities: HAL =
>>>>>>> 8150100, FW = a70414, HW = 620003, Model = 0, HCI = 1, Full_FW = 104,
>>>>>>> FW Update Info = 0
>>>>>>> 05-12 22:08:54.769: DEBUG/NFCJNI(303):
>>>>>>> phLibNfc_SE_GetSecureElementList()
>>>>>>> 05-12 22:08:54.769: DEBUG/NFCJNI(303): > Number ofSecure
>>>>>>> Element(s) : 1
>>>>>>> 05-12 22:08:54.769: DEBUG/NFCJNI(303):
>>>>>>> phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
>>>>>>> 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_SetMode() returned
>>>>>>> 0x000d[NFCSTATUS_PENDING]
>>>>>>> 05-12 22:08:54.828: INFO/NFCJNI(303):NFCInitialized
>>>>>>> 05-12 22:08:54.828: DEBUG/NfcService(303):NFC-EE routing OFF
>>>>>>> 05-12 22:08:54.847: DEBUG/NfcService(303):NFC-C discovery ON
>>
>>>>>>> BUT reader is not detecting a Tag on my phone
>>>>>>> Is there maybe a problem to setting the mode
>>>>>>> returned 0x000d[NFCSTATUS_PENDING] sounds not so great
>>
>>>>>>> I am working with CyanogenMod 7 (Android 2.3.4)
>>
>>>>>>> regards
>>>>>>> Markus- Hide quoted text -
>>
>>>>>> - Show quoted text -
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
