nfc - Android HCE: are there rules for AID?

nfc - Android HCE: are there rules for AID?

Ethan Savitr Author: Ethan Savitr Date: 2022-10-05
nfc - Android HCE: are there rules for AID?

All you need to know about nfc - Android HCE: are there rules for AID? , in addintion to java - Are there advantages for using SpongyCastle over BouncyCastle, if targeting Android 3.0 and later? , android - Are there any official APIs/Samples/Tutorials for implementing the new Material-Design-guidelines? , android - Configure MIFARE DESFire EV1 as NFC Forum Type 4 Tag for NDEF , facebook audience network - After upgrade to target 29,there are so many crashes on android 10 /apex/com.android.runtime/lib64/libart.so (art::OatFileManager::DumpForSigQuit

  1. nfc - Android HCE: are there rules for AID?
  2. Question:

    I'm trying to use an ACR122 NFC reader to select an application emulated in one Nexus 5 using Android Host Card Emulation. However, small AIDs are not recognized.

    My goal is to use a three byte long AID, as I do in a DESfire card. My first goal is only to be able to do a SELECT command.

    My test app uses the following configuration for AIDs:

    <host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:description="@string/service_descr"
    android:requireDeviceUnlock="false" >
    
        <aid-group
            android:category="other"
            android:description="@string/aid_descr" >
                <aid-filter android:name="A0A1A2" />
                <aid-filter android:name="B0B1B2B3" />
                <aid-filter android:name="C0C1C2C3C4" />
                <aid-filter android:name="D0D1D2D3D4D5" />
                <aid-filter android:name="E0E1E2E3E4E5E6" />
        </aid-group>
    
    </host-apdu-service>
    

    If I run the following APDUs:

    00 a4 04 00 03 a0 a1 a2 00
    00 a4 04 00 04 b0 b1 b2 b3 00
    00 a4 04 00 05 c0 c1 c2 c3 c4 00
    00 a4 04 00 06 d0 d1 d2 d3 d4 d5 00
    00 a4 04 00 07 e0 e1 e2 e3 e4 e5 e6 00
    

    I always get the following responses:

    => 00 a4 04 00 03 a0 a1 a2 00 
    <= 6f 00 
    => 00 a4 04 00 04 b0 b1 b2 b3 00 
    <= 6a 82 
    => 00 a4 04 00 05 c0 c1 c2 c3 c4 00 
    <= 90 00 
    => 00 a4 04 00 06 d0 d1 d2 d3 d4 d5 00 
    <= 90 00 
    => 00 a4 04 00 07 e0 e1 e2 e3 e4 e5 e6 00 
    <= 90 00 
    

    So, only AIDs with length greater than 5 bytes will work with Android? Or am I doing something really wrong?


    Solution 1:

    The rules for smartcard application identifiers (AIDs) are defined in ISO/IEC 7816-4. An AID may consist of up to 16 bytes. Based on the first 4 bits, AIDs are divided into different groups. The most relevant groups defined in ISO/IEC 7816-4 are:

    • AIDs starting with 'A': internationally registered AIDs
    • AIDs starting with 'D': nationally registered AIDs
    • AIDs starting with 'F': proprietary AIDs (no registration)

    For (inter)nationally registered AIDs, the AID is split into two parts, a 5-byte mandatory RID (registered application provider identifier), and an optional PIX (proprietary application identifier extension) of up to 11 bytes.

    For proprietary AIDs (F...) ISO/IEC 7816-4 does not clearly mandate any minimum length requirements.

    In addition to this, when it comes to HCE and routing of card emulation communication from the NFC controller to secure elements or the application processor, there is the NFC Forum NCI specification. This specification mandates an AID (used in AID-based routing entries) to be between 5 and 16 bytes. Btw. the same limitation applies to smartcards following the Java Card specifications.

    When it comes to Android, there is a hard-coded requirement that AIDs received in a SELECT command consist of at least 5 bytes:

    • In method resolveAid() in RegisteredAidCache.java on line 142
    • In method findSelectAid() in HostEmulationManager.java on line 390 (which actually causes the odd behavior that the 4 byte AID is rejected with a "File or application not found" (6A82) status word as the check does not properly account for the Le byte)

    Solution 2:

    According to EMV standards, an AID is made up of a Registered Application Provider Identifier (RID) having a minimum of 5 bytes, and an optional Application Identifier Extension (PIX) or proprietary Application Identifier having a maximum length of 11 bytes, which together make up the Application ID (AID), thus, the application ID can never be less than 5 bytes in length. If there are several applications present in the card, the AIDs will have the optional app identifiers appended to the RID to differentiate between the applications present in the card. Please read up on EMV standards on their site: EMVCO, and especially their books, Book 1 to Book 4, to understand more in this.

  3. java - Are there advantages for using SpongyCastle over BouncyCastle, if targeting Android 3.0 and later?
  4. Question:

    If I understand the situation correctly, SpongyCastle is a renaming of BouncyCastle and it was created to give people the ability to include a new version of BouncyCastle on Android, since just including the latest BouncyCastle jar would cause conflicts with the old and stripped down version of BouncyCastle that came with Android.

    However, apparently since version 3.0 (in 2011 - 6 years ago!) the Android BouncyCastle package was renamed to com.android.org.bouncycastle, so that now if you included the regular org.bouncycastle, this would no longer conflict with the pre-packaged stripped down BouncyCastle, and you could use the newest version that way.

    What confuses me is that it seems like the SpongyCastle project is still quite active and whenever I search for "BouncyCastle on Android" or anything related, I get a lot of results from the last couple of years which recommend using SpongyCastle, citing the class conflict issues as the reasoning, even though they were (apparently) resolved all the way back in 2011. Another argument I've seen that makes more sense to me, is that SpongyCastle is more backwards compatible, since you won't get any issues on devices running earlier versions Android than 3.0.

    So my question is, are there still any benefits to using SpongyCastle over BouncyCastle, if you are not targeting earlier versions of Android than 3.0?


    Solution 1:

    Here's what the author of Spongy Castle wrote on this:

    Why might Spongy Castle not be obsolete?

    • pre-Android 3.0 devices are still in active use. There are higher areas of use in poorer countries, and those people still need secure cryptography. Signal (not a SC user, so far as I'm aware) currently still supports Android 2.3 and up.
    • even on post-Android 3.0 devices, device manufacturers are not above carelessly bundling libraries, it's possible that Bouncy Castle may still be bundled on some obscure devices.
    • Although the version of Bouncy Castle bundled with Android has a changed package name, it still has "BC" as the provider name, leaving some ambiguity as to the choice of implementation when adding your own copy of Bouncy Castle to the app and choosing "BC" as your provider.

    But he then he went on to note that Spongy Castle releases often lag behind the Bouncy Castle releases ... for reasons which are entirely understandable.


    In short, for an Android device the only possible benefits in using Spongy Castle would appear to be to deal with cases where your application needs a recent Bouncy Castle functionality, but device manufacturers have bundled an old version.

  5. android - Are there any official APIs/Samples/Tutorials for implementing the new Material-Design-guidelines?
  6. Question:

    Background

    Google has recently added a lot of guidelines for designers (here), including plenty of animations of how things can work.

    The problem

    As I've read the guidelines, I decided to try out the new design, and use the support library.

    Sadly, for many (or maybe all?) of them, I can't find out how to implement them using the official APIs that Google has given.

    For example, I've tried to find out how they've implemented this cool scrolling effect called "Flexible space with image" (taken from here) : link . However, no matter where I search, the only thing I find is of third party libraries (like this one).

    Another example is the way to create a Material-design raised button style (posted about it here)

    What I've found

    I've found only tiny snippets (and more guidelines) of very specific elements, on the android developers blog, for example here and here , but that's not nearly enough for using it, let alone support pre-Lollipop versions of Android (and that's most of the devices right now).

    I've also found this documentation , but again, it lacks a lot of explanations to what is shown on the designers' website (here).

    The question

    Are there any APIs/Samples/Tutorials for any of the new Material design guidelines?

    Anything other than what I've found?

    Is it possible the support library barely supports the new design? I couldn't even find dialogs support and Prefereces in it, so I made something (based on someone else's library) here ...

    It's just really weird that there are so many animations examples, but no actual code to try and use for best practice...


    Solution 1:

    While the new API provides some new UI elements like like CardView (that have been already included in the support library) there are no new specific APIs for material animations, those animations abilities already exist in the current API.

    The Material theme does provide default animations and activity transitions, however you need to do the rest by your self and as mentioned in this tutorial.

    So long story short, while the new Android API 21 came with new components, you will still have to implement the majority of the design by your self.

    Solution 2:

    Solution 3:

    Hi here the url I found when I googled "android lollipop apps github" https://github.com/mikepenz/LollipopShowcase

    I've used Android Studio 1.0 to git clone the source code, try it its fun

  7. android - Configure MIFARE DESFire EV1 as NFC Forum Type 4 Tag for NDEF
  8. Question:

    I started my studies using NFC in Android. I can easily read and write in NDEF format.

    My problem is with MIFARE DESFire EV1, I have some factory cards and I understand that they do not conform to the NFC Forum type 4 Tag specification and, consequently, do not accept to be read or written in NDEF format (when in their factory configuration).

    I can get access to the tag through android.nfc.tech.NfcA or android.nfc.tech.IsoDep.

    So far I understand that I need to use IsoDep.transceive() method to pass commands that enable me to build an NFC Forum Type 4 compliant tag.

    But I'm having a lot of trouble. I'm using TagWriter and it does the service perfectly. Every time I use the NDEF dataset it automatically performs a routine that makes the card an NFC Forum Type 4 Tag and, consequently, an NDEF tag.

    However, I could not find any simple example to do this procedure myself. Even after reading the specification document NFCForum-TS-Type-4-Tag_2.0, I'm still very lost.

    Is there any practical example to do the process that the TagWriter application does?

    • Recognize NfcA / IsoDep (ok here)
    • Make the card conform to the NFC Forum Type 4 Tag specification
    • Start recognizing the tag as android.nfc.tech.Ndef
    • Enable read and write of NDEF


    Solution 1:

    The procedure to prepare MIFARE DESFire EV1 as an NFC Forum Type 4 Tag (V2.0) is not part of the platform independend NFC Forum specifications. Instead, this procedure is defined by the chip manufacturer (NXP) in their application note AN11004: MIFARE DESFire as Type 4 Tag. The procedure is about the following:

    1. If Android already detects the Ndef tag technology, you are done. Since Android tries to detect the NDEF tag application and an NDEF message contained in the NDEF data file, finding the Ndef tag technology means that the tag is already prepared for NDEF (i.e. it already is configured as NFC Forum Type 4 Tag).

    2. Else, you would check if the tag really is a DESFire EV1 tag. You can do this based on the type identification procedure described in AN10833: MIFARE Type Identification Procedure and based on the version information obtained from the DESFire tag.

    3. Once you know that the tag is a DESFire EV1 tag (and that you have sufficient access to the master application in order to apply the necessary modifications to the tag, which may require and authentication step), you would first create the NDEF Tag Application. This is a DESFire application that has its ISO 7816-4 DF name (= AID) set to D2760000850101 during creation. The values that you chose for the DESFire AID, the ISO file ID are not important for proper T4T operation (note that this is different for the pre-EV1 generation of DESFire). The key settings depend on your usage scenario. The only other important parameter that you need to set during application creation is to allow ISO 7816-4 file identifiers for files within the application (bit 5 in the Key Settings 2 byte set to '1').

    4. Select the newly created application.

    5. Create a new standard data file, the capability container file, with a size of 15 bytes. You need to set the ISO 7816-4 file ID to E103. Make sure to allow plain communication by setting the Com.Set. byte to 0x00. Set the Access Rights field so that you can later modify the file contents during the initialization.

    6. Create another new standard data file, the NDEF data file. If you only use the tag as NDEF tag, you would typically use all the remaining available space. Set the ISO 7816-4 file ID to E104. Make sure to allow plain communication by setting the Com.Set. byte to 0x00. Set the Access Rights field to 0xE000 for a read-only tag or 0xEEE0 for a tag that should allow read and write access through the Ndef tag technology.

    7. Select the capability container file and write the capability container data to it:

      000F  20  003A  0034  04 06 E104 xxxx 00 yy
      

      where xxxx is the size of the NDEF data file and yy is 0x00 if the file is freely writable or 0xFF if the file is read-only.

    8. Select the NDEF message file and write the first 2 bytes as 0x0000 (in order to indicate that the file is empty).

    Note that creating the NDEF Tag Application structures on a DESFire (EV1) card requires you to use either the native or the wrapped native command set of MIFARE DESFire. Since some versions of Android cause known problems with the native commands, you are better off using wrapped native commands. You can find details on the DESFire command set in the DESFire product datasheets (available only under NDA from NXP).

  9. facebook audience network - After upgrade to target 29,there are so many crashes on android 10 /apex/com.android.runtime/lib64/libart.so (art::OatFileManager::DumpForSigQuit
  10. Question:

    After upgrading target sdk version to 29, there are so many crashes on android 10:

    backtrace:
      #00  pc 0000000000082fb4  /apex/com.android.runtime/lib64/bionic/libc.so (abort+160)
      #01  pc 00000000004b4888  /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+2268)
      #02  pc 000000000000c5b4  /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+608)
      #03  pc 0000000000442f8c  /apex/com.android.runtime/lib64/libart.so (art::OatHeader::GetCompilerFilter() const+280)
      #04  pc 000000000044a884  /apex/com.android.runtime/lib64/libart.so (art::OatFile::GetCompilerFilter() const+40)
      #05  pc 0000000000455d38  /apex/com.android.runtime/lib64/libart.so (art::OatFileManager::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+376)
      #06  pc 00000000004c1d78  /apex/com.android.runtime/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+104)
      #07  pc 00000000004d5ad8  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+1356)
      #08  pc 00000000004d4b6c  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::Run(void*)+252)
      #09  pc 00000000000e205c  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
      #10  pc 0000000000084af0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
    

    build.gradle is following

    implementation 'com.android.installreferrer:installreferrer:2.1'
    implementation "com.google.android.gms:play-services-base:17.4.0"
    implementation "com.google.android.gms:play-services-gcm:17.0.0"
    implementation "com.google.android.gms:play-services-ads:19.3.0"
    implementation "com.google.android.gms:play-services-auth:18.1.0"
    implementation "com.google.android.gms:play-services-location:17.0.0"
    implementation "com.google.firebase:firebase-core:17.5.0"
    implementation "com.google.firebase:firebase-messaging:20.2.4"
    implementation "com.google.firebase:firebase-config:19.2.0"
    implementation 'com.google.firebase:firebase-auth:19.3.2'
    implementation 'com.google.firebase:firebase-crashlytics:17.2.1'
    implementation "com.facebook.android:facebook-login:5.15.3"
    implementation "com.facebook.android:facebook-messenger:5.15.3"
    implementation 'com.facebook.android:audience-network-sdk:5.8.0'
    

    Anyone seeing similar issues knows what's going on?


    Solution 1:

    Update audience-network-sdk to version 6.1.0 can fixed the bug. Tested with some devices on firmware 10