My agency just got their first prototype desfire card that is anticipated to go into production (50K employee agency). I'm trying to connect to, authenticate and read a particular file. So when I present my android device, onDESFIRECardDetected is fired. I connect to the tag (desfire object), authenticate by passing my agency's master and app key and providing the appId. My next step is to try to read a particular file within the application. I don't see any method that accepts the fileId??? I see the command 'Read(int iNoOfBytes)', which the javadoc states, "iNoOfBytes - Number of bytes to read", but from where???. However, when I run my application and put in an arbitrary value for the parameter (e.g. say, 1), an exception is thrown stating, "File Not Found".
Basically, how do I read a particular FileID within an application for a Desfire card using the SDK???
So after consulting with nxp the last couple of days, it turns out this is a limitation with the LITE version. I was told this ability will be available in the advanced version but as of this post, it is not available.
Yes, you are right. Only limited support to DESFire is provided by lite version. Most feature provided by DESFire is not included in the lite version, specially the security related operation. This could be done using api in advanced SDK:
byte[] readData(int fileNo,
int offset,
int length,
DESFireEV1.CommunicationType comSettings);
Or, you need to read the MF3ICD81 functional specification and do all the things from the scratch.
Related
I work on application that communicate with a custom SIM card with use of Android OMAPI. The application had worked, before I updated Google Pixel to Android 13. Since then, when openLogicalChannel of the Session is called, I get the exception below with scarce information:
Caused by: java.io.IOException: OpenLogicalChannel() failed
at android.se.omapi.Session.openLogicalChannel(Session.java:322)
at android.se.omapi.Session.openLogicalChannel(Session.java:359)
I haven't found any information about OMAPI changes or additional permission in Androdid 13 documentation.
isSecureElementPresent of Reader returns true.
Does anybody have any clues?
As you commented you are not using Android carrier privileges. I'm wondering how this was ever working in your case. In all my setups I needed it for accessing the SEService. The Access Control Enforcer was always checking the access properly in my Pixel devices. Was your previous Pixel device rooted before?
Please try to add the hash of your signing certificate to the ARA or use a generic allow all rule. Maybe you can install this allow all applet on the SIM. For analyzing the APDU traffic I have written an XPosed module displaying additional log messages in the Android radio log.
Using android device to nfc read my country ID card and Driver license (hint: both had 3 lines MRZ of Type TD1 and the Driver card has a number 8digits+'E' near the chip, witch I don't know what is used for!?)
for ID card part I used jmrtd library (BAC protocol, and I successfully read all what I want Data Group {1,2,11,12})
for Driver License, after reading some standards I supposed to do BAP instead-of BAC So I implemented a DLicenseService class the same as PassportService but with some minor changes:
changed EF_COM to 001F and AID to A0000002480200 (witch worked in the first tries) ...
I'm doing BAC as BAP with a custom key derivation algorithm the triplet (docNumber, dateOfBirth, dateOfExpiry) did not work...
My questions are:
Is there any protection against a wrong key derivation multiple attempts (assuming BAP == BAC) because the scuba service now is failing!!...please don't tell me there is and my card is blocked...
Are BAP and BAC equivalent? should I try other protocol?
Do you know the most used key seed derivation algorithm for Driver License (like SHA1 of last 6 doc digits...)
Is there a library to deal with Driver License like jmrtd for travel document?
Yes, BAC and BAP are equivalent
The triplet worked for Driver licence
I implemented all my logic on top of jmrtd code and every think worked fine, basically I implemented :
DLicenseService class
COMFile and all DGxFile that I'm interested in taking into account the correct SFI and Tags values from the iso/IEC FCD 18013-2 standard.
While trying to carry out an encryption and decryption process on an Android environment, i have the below log.
com.s.sdk.security.SMException: Error loading Local Master Keys, file:
"/cfg/lmktest.lmk" does not exist. Please specify a valid LMK file, or
rebuild a new one. 09-21 11:56:31.792 16182-16182/com.mpos.sdk
W/System.err: at
com.s.sdk.security.jceadapter.JCESecurityModule.init(JCESecurityModule.java:1785)
09-21 11:56:31.792 16182-16182/com.mpos.sdk W/System.err: at
com.s.sdk.security.jceadapter.JCESecurityModule.(JCESecurityModule.java:159)
The reason why I will want to make use of JPOS is simply because I will want to carry out a financial transaction, which will be used in packaging my message.
For the encryption and decryption of data, I am to make use of this JCESecurityModule which works well on other platform, but not on the android OS.
NOTE: The file location in my android studio is app/cfg/test.lmk
I was able to get this file from the JPOS-master on github found in the jPOS-master\jPOS-master\jpos\src\test\resources\org\jpos\security
i.e the lmk-test
which was been used this way
JCESecurityModule sm = new JCESecurityModule("app/cfg/test.lmk");
I have also tried rebuilidng the lmk file, using the below method
public JCESecurityModule (String lmkFile) throws SMException
{
init(null, lmkFile, true);
}
which can be found in the JCESecurityModule class (JPOS)
was still having same issue in loading the lmk file
Thanks
For the sake of completeness, this was also asked on the jPOS's Google Group, and discussed there. https://groups.google.com/forum/#!topic/jpos-users/X3r_PX7lgd4
The encryption was done by a device which is to be connected to a mobile phone to carrying out transactions, but the device makers actually did it this way to provide end to end encryption which you are circumventing. You don't need jpos in the device. You need it at your centrally deployed servers, where you would use real HSMs.
by Victor Salaman
in JPOS users google group https://groups.google.com/forum/#!topic/jpos-users/X3r_PX7lgd4
but you can still carry out the encryption and decryption using some other Module instead of the JCESecurityModule (if the problem still persist). e.g. using the SunJCE
I have found several sources describing a String Format used to describe WiFi-Access Settings in the form of:
WIFI:T:WPA;S:mynetwork;P:mypass;;
(example taken from zxing documentation)
For basic WPA-Connections, this works just fine on my Android Device using the Zxing-Barcode-Scanner-App. However, I have been unable to find a way to embed WPA2/EAP-Connection Settings (Also referred to as WPA2 Enterprise) into a scannable 2D-Code. As I expected, inserting "L" (Login), "N" (Name) or "I" (Identification) Parameters at random positions did not really bring any advance.
Has anyone here succeeded in "embedding" WiFi-Connection Settings into a 2D-Scannable Code to work with an Android device?
Thanks for your help!
I found some information on how to format the WiFi config string in the following pull request at the github page of the zxing library project: https://github.com/zxing/zxing/pull/865
The first post contains a template of the string format, including an error (the prefix AI: is wrong, it must read A:, see here). The correct format according to the source is thus:
WIFI:T:WPA2-EAP;S:[network SSID];H:[hidden?];E:[EAP method];PH2:[Phase 2 method];A:[anonymous identity];I:[username];P:[password];;
When I tried this (using the command line tool qrencode) my Barcode Scanner app crashed. After some trial and error I figured that the option for hiding the SSID can be left out:
WIFI:T:WPA2-EAP;S:[network SSID];E:[EAP method];PH2:[Phase 2 method];A:[anonymous identity];I:[username];P:[password];;
With this I'm getting a working entry in the list of known wireless networks in Android 8.
As of now there is no support for declaring a certificate and the respective domain. If this is needed, one can specify it later by adjusting the settings from inside Android's WiFi menu.
I updated my Android phone to 4.0.4 and i noticed that a new file nfcee access.xml appeared in the system folder. The idea of the file as far as i understood is the keep a list of signatures, and allow access to the SE and related intends only to the packages that are signed with one of this signatures. So far in this list is of course the signature of the Google Wallet.
Does anybody know how would be the process in future to enter this list? Do you need to ask for permission directly Google?
If you root your phone, you can modify the file. The file contains the list of signatures and package names that are allowed access to the Secure Element (SE). The signatures is a hex-encoded X.509 certificate. To create one, simply include the tag <debug /> in the file and it will print to logcat the hex-encoded signature of applications that are denied SE access, for easy cut-and-paste into this file.
To create an app that can access the SE, you need to add this permission to the manifest:
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" />
To actually access the SE, you need to access a hidden API by importing com.android.nfc_extras:
import com.android.nfc_extras.NfcAdapterExtras;
import com.android.nfc_extras.NfcAdapterExtras.CardEmulationRoute;
import com.android.nfc_extras.NfcExecutionEnvironment;
The easiest way to make this possible is to compile your app in the Android source code tree by placing it in packages/apps and building it from there. You need to add the following line to the Android.mk makefile to get access to the SE API:
LOCAL_JAVA_LIBRARIES := com.android.nfc_extras
The functions in com.android.nfc_extras allow enabling and disabling the SE, sending commands to it and receiving responses from it (comparable to IsoDep.transceive()).
This is interesting indeed. If entering your certificate and package name in this file is all that is needed, you shouldn't need to talk to Google, just get whoever is building the ROM (yourself if custom ROM, or a particular carrier) to include it. The bigger problem though is,
who do you need to talk to to get the CardManager keys. If it is the carrier, you can also get them to pre-install your applet, so you might not need the keys at runtime (unless you want to use a secure channel to your applet).
Update: Here's a summary of SE support in Android and some more info on how to use the embedded one. In short, it does work, but you can only query stuff of course. It runs JavaCard and is GP 2.1.1 compatible, uses 3DES keys for the secure channel.
http://nelenkov.blogspot.com/2012/08/accessing-embedded-secure-element-in.html
http://nelenkov.blogspot.com/2012/08/android-secure-element-execution.html
BTW, here's the currently allowed cert on my GN 4.0.4. A package is not specified, so any app signed with it will get access to the SE:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a8:cd:17:c9:3d:a5:d9:90
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
Validity
Not Before: Mar 24 01:06:53 2011 GMT
Not After : Aug 9 01:06:53 2038 GMT
Subject: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
With cavets: If you can get your application on the nfcee_access list you can do the following things:
Enable the UICC (sim card) and enable the embedded secure element (if present)
Open a communication channel to the embedded secure element and exchange data
Receive transaction data from the UICC (sim card) if the UICC wants to send you data (you'll be receiver only).
You can do all this if you root your phone. No need to hack the nfcee_access list to do so, you can just intercept all traffic to the nfc-chip to so so.
What you can't do, even with a rooted phone:
Install applets on the UICC / eSE
Log/Monitor/influence the data-transfer between the embedded secure element/UICC and an external reader, e.g. hack payment systems.
Caveat: You can do almost everthing if, and only if you have the knowledge and the secure access-keys to access the embedded SE. However, if you have these information you wouldn't ask on stack-overflow. :-)
This knowledge is a well kept secret and no one will tell you this secret unless you are a company as big as google, mastercard, visa, american-express and the like.
The answer is simply NO you cannot do anything with the Secure Element. Only SE owner or issuer can allow the access to the SE - i.e. it is Google itself, or might be First Data (http://www.firstdata.com/en_us/products/merchants/mobile-commerce/trusted-service-manager-solution.html), but I think this company is responsible only for the Google Wallet itself, not for the SE management - this might done by SK C&C - I have no idea...
Take it also that way - the precondition for using embedded secure element is that you are offering excellent service and you are Google partner or other phone manufacturer partner (unless you are from Facebook or similar company save your time and do not try that). This is not easy and 99.99% of services cannot be there.
Regarding secure element now you can wait until SWP and SIM cards will become more popular and acceptable solution, since you might be able to get contract with MNO on national level easier or hope in NFC-WI and SD card solution or go with stickers or external accessories like iCarte for iPhone.