Develop Reference

OMAPI OpenLogicalChannel failed on Android 13

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 JCESecurityModule on Android device

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

How to call AccountManager's peekToken() from several apps sharing the same authenticator in api <= 22

I've created a library where all the authentication is configured, including AccountManager's authenticator class. This library is intended to be used by different apps and with different signing certificates.
The scenario is the following:
Two apps importing installed in the device both importing the library. I'm adding an account to the AccounManager from one of them, and then calling AccountManager's peekAuthToken() from both. It works for api < 22 (it is indicated in the docs) but returning a SecurityException in lower APIs (which is expected).
What would be the way to accomplish that in lower versions?
I have also try to use getToken instead, which returns a Future object, but the future.getResult() seems to fail at some point (no kind of exception is shown) and never returns the result with api <=22 and different signing certificates.
Any clue?

It can be solved adding the following att to the authenticator.xml configuration file: android:customTokens="true"
It will look as:
I'm not sure what is happening internally with this att enabled.

Phonegap https-app: release version can't send data, debug version can

can anyone help me with the following question please:
My Android-App is able to send the data via https when compiling the debug-version, but the release version fails there.
The https certificate is not self-signed and the whitelist plugin is working.
Interesting is, that if the debug version is installed and then the release version is installed without deinstalling the debug-version, everything works out well.
Can anyone help me here? Thank you in advance!

Problem solution:
The SSL-Chain was the problem for me.
1) To check if this might be an issue for your app, too, you may go to:
https://www.digicert.com/help/
Type in your domain (if already available online) and test your SSL-Configuration. If the last point does not say "SSL Certificate is correctly installed" and you bought your certificate from a trustworthy authority, this website already hints you at an issue you might have with the intermediate certificates.
2) Fix issue:
a) The intermediate certificates neccessary came with that SSL.rar-file you've once gotten. With the provider I had chosen, they sent me three .pem files (besides of other files of course) named:
01_COMODO_RSA_Organization_Validation_Secure_Server_CA, 02_COMODO_RSA_Certification_Authority,
03_AddTrust_External_CA_Root
Other authorities might send you something like someName.ca-bundle. That's the same thing, as far as I understood it, and so can skip this a) part.
Concatenate the plain text of these three files, meaning store them in another file - altogether. No additional text changes neccessary. When storing this file, make sure it has the .crt file ending.
b) Upload your chosenName.crt to your server into the same folder your ssl.crt is stored in already.
c) Make this new file known within the system. In your .config file (e.g. default-ssl.conf), the same file you once added the paths to your "ssl".crt and .key in, set "SSLCertificateChainFile" to - example path: "/etc/ssl/ssl.crt/chosenName.crt" - and update the certficates (I used the command update-ca-certificates, but I'm not sure if this was neccessary at all.)
d) Stop and start your webserver. If an error message regarding wrong configuration is displayed, you have probably misstyped the path to the file or it's name and so it cannot be found. If your webserver starts successfully, you're done.
Another check on the link above (I am not allowed to have more than 2 links within this post) should now show you the SSL-Chain (containing now 4 instead of 1 certificate_s) and the above mentioned "SSL successfully installed" message should appear.
Hopefully this will help you!
Further info:
Whether you need this SSL-Chain with 4 certificates or not is probably something that can vary. I looked it up on the comodo-support site because that was the SSL-certificate authority I had to deal with:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/620/0/which-is-root-which-is-intermediate

When creating CLIENT ID: "An unexpected error has occurred. We're looking into it."

I am getting "An unexpected error has occurred. We're looking into it." when creating CLIENT ID
It did not happened before.
But recently I follow the new guide by Stephen Wylie, delete the whole project and start fresh
The first 2 times i delete and create new API project, it was ok.
But today I try again, and the error appears.
I cannot continue right now.
Another side question, when will the official Android sample be posted?
It had been promised for few months.
Unlike dropbox, box, skydrive, they all have very good sample that allows people to integrate into their app in few hours or even less than half hour if you are experienced.

The package name/signing certificate fingerprint (SHA1) pair has to be unique and that includes deleted projects. If you need to create a new API project and don't want to change the package name, you can also generate a new keystore file to sign your application and use its signing certificate fingerprint instead of the former one.