I've recently been developing a solution around the Secure Key Import feature of Android (info here) and have run into a problem.
I follow the procedure as documented. On the final step, when calling keyStore.setEntry(...) I get thrown an error with the code -1000 which is KM_ERROR_UNKNOWN_ERROR (error codes). I really don't have an idea on how to proceed from here. Any ideas on where the problem might be?
Some relevant code:
// (app) send attestation challenge request to server
// (server) generate and send challenge to the app
// (app) use challenge to generate a PURPOSE_WRAP_KEY key pair
// (app) get certificate and send to server
// (server) do wrap operations and return a blob (ASN.1 sequence as required in docs)
// (app) code below
byte[] wrappedKeySequence = response.body().getSequenceAsBytes();
AlgorithmParameterSpec spec = new KeyGenParameterSpec.Builder(WRAP_KEY_ALIAS, KeyProperties.PURPOSE_WRAP_KEY)
.setDigests(KeyProperties.DIGEST_SHA256)
.build();
KeyStore.Entry wrappedKeyEntry = new WrappedKeyEntry(wrappedKeySequence, WRAP_KEY_ALIAS, WRAP_ALGORITHM, spec);
String keyAlias = "SECRET_KEY";
keyStore.setEntry(keyAlias, wrappedKeyEntry, null);
More random details:
I'm trying to import an AES128 key
It'll be only used for encrypting data
Targeting API 28 and above, as required by the docs
Again, any help would be greatly appreciated.
Thanks,
G.
Update:
I've found the reason for this specific error, but have come to another error.
Namely, I used the tag 403 which defines MIN_SECONDS_BETWEEN_OPS. It being in the types.hal file, one would expect it to be implemented/valid everywhere, but it seems this isn't the case. However, I'm testing only on one Samsung phone, so it might be implemented by other manufacturers, or even on other Samsung phones.
Anyway, the next error is INVALID_ARGUMENT (-38) which, unlike the name suggests is as cryptic as this one. The docs say that it should occur for the RSA stuff (I'm trying to import an AES key), so the saga continues.
I'll update this answer if I find anything else.
Update 2:
I don't have any good news regarding the INVALID_ARGUMENT error. I get it even when I execute the unedited CTS test code, which is supposed to work, as the manufacturers use the CTS tests for validating that the devices work before leaving the factory.
For now I've paused work on that feature, if I ever come back to it I'll update as necessary.
Related
I'm seeing app crashes in production on Android 12 and 13 (so far) as follows when calling Signature.initSign:
android.security.keystore.UserNotAuthenticatedException: User not authenticated
at android.security.keystore2.KeyStoreCryptoOperationUtils.getInvalidKeyException(KeyStoreCryptoOperationUtils.java:128)
at android.security.keystore2.AndroidKeyStoreSignatureSpiBase.ensureKeystoreOperationInitialized(AndroidKeyStoreSignatureSpiBase.java:217)
at android.security.keystore2.AndroidKeyStoreSignatureSpiBase.engineInitSign(AndroidKeyStoreSignatureSpiBase.java:123)
at android.security.keystore2.AndroidKeyStoreSignatureSpiBase.engineInitSign(AndroidKeyStoreSignatureSpiBase.java:101)
at java.security.Signature$Delegate.init(Signature.java:1357)
at java.security.Signature$Delegate.chooseProvider(Signature.java:1310)
at java.security.Signature$Delegate.engineInitSign(Signature.java:1385)
at java.security.Signature.initSign(Signature.java:679)
The flow I'm following is:
generate a key pair in the android keystore with a sole purpose of
KeyProperties.PURPOSE_SIGN. The code is similar to the KeyPairGenerator sample here: https://developer.android.com/training/articles/keystore#UsingAndroidKeyStore (In my case UserAuthenticationRequired is
true, invalidatedByBiometricEnrollment is false)
later, when signing is required, retrieve the private key from the keystore and call initSign(privateKey)
Now launch the BiometricPrompt (passing in the initialised Signature as part of the Cipher object)
Once the user has successfully authenticated, then call Signature.update and Signature.sign on the returned Signature.
I might expect the crash at step 4 if the user had failed to authenticate, or if a weak authenticator was used, but this crash is happening at step 2 when calling initSign. The user can't have authenticated here, as initSign must be called on the signature before passing it to the biometric prompt.
What could cause this? The crashes occur across multiple devices and once users experience this it repeats consistently, so doesn't seem to be a rare edge case. I cannot replicate this locally on a variety of devices on Android 12 and 13 so in theory the flow works.
so here's a quick explanation of my issue - my current setup is and IdentityServer4 implementation with ASP.NET Core Identity, an API resource protected by it and a Xamarin.Android application that is the client. My current issue is that the client(Android) cannot get anything from the API because of the following error(from the API logs):
"Bearer" was not authenticated. Failure message: "IDX10205: Issuer validation failed. Issuer: 'http://10.0.2.2:5000'. Did not match: validationParameters.ValidIssuer: 'null' or validationParameters.ValidIssuers: 'http://127.0.0.1:5000'."
Basically, since I'm using the Android emulator, in order to call something that's on localhost on my machine, I need to use the 10.0.2.2 URL for it. Then the problem pops up - the Identity Server is fine with authenticating, I can login fine, I get an access token, but after that I need to call the API. And that's where the error happens - it's expecting an issuer that is with the same authority(127.0.0.1:5000) but receives the 10.0.2.2:5000, which is the authority for the Android client.
So, my question is - is there a way to somehow specify that 10.0.2.2 is also a valid issuer, or do I have to start thinking about deploying both the API and the Identity Server just so I can test the client. I'd really like it if there was a way to have the whole solution running on my local machine rather than having to deploy for every little thing I want to try out.
Any help will be appreciated very much.
First: Given the standard, you manage just one Issuer.
Are you managing your own Identity / Token generation? It sounds like this isn't the case.
You could customize your API for creating your tokens explicitly. Then, you can indicate a global Issuer (like your project url) so anyone can validate against the same.
var token = new JwtSecurityToken(
issuer: "http://my-perfect-proj.net",
claims: ...,
notBefore: DateTime.Now,
expires: DateTime.Now.AddHours(1),
signingCredentials: ...)
);
After your token is created and sent, validate your incoming request based on your tastes (checking time, user's data, issuer).
ASP.NET Core JWT Bearer Token Custom Validation
Creating RESTful API with Authentication
EDIT: Using Xamarin and Visual Studio on the same machine, didn't gave me this kind of problems but in that case, I was using Visual Studio Emulator. You could give it a try and avoid doing other types of workarounds.
So, I managed to work around the issue by simply running the Web part of it so it's visible on my local network. What I did in more detail - in the Program.cs where I create the host, I use the .UseUrls("http://*:5001") method, and then I run the app with dotnet run.
In this way your app is accessible in your local network via the IP address of your machine and the port you've specified. Also, in order for this to work, you'd have to define a new Outbound Rule in your Firewall to allow traffic through that port you're using. Hope this helps someone else as well, this turned out to be the easiest way to get what I need to work, and that's after fighting with IIS for a while trying to get it to work through there as well.
Short answer: In IIS, don't leave the site binding host name set as blank.
Longer explenation:
I received a similar error, but could see that for some reason it was trying to match the issuer domain name vs IP (the domain does point to the IP, but I guess it tries to validate the two strings). I could see this error after allowing logging : IdentityModelEventSource.ShowPII = true.
Microsoft.IdentityModel.Tokens.SecurityTokenInvalidIssuerException:
IDX10205: Issuer validation failed. Issuer: 'http://ec2XXXXXom'. Did
not match: validationParameters.ValidIssuer: 'http://34.111.111.29' or
validationParameters.ValidIssuers: 'null'. at
Microsoft.IdentityModel.Tokens.Validators.ValidateIssuer(String
issuer, SecurityToken securityToken, TokenValidationParameters
validationParameters)
In IIS I previously had the host name set as blank (I am using the server name as domain name) - and therefore it set the issuer using the IP of the server. When I specifically set the site domain name, it worked.
I have a problem restricting a Google Cloud Platform API key usage to an Android app: I have added its package name and certificate SHA-1 fingerprint (the debug one to get started) but it doesn't work.
The error I get when calling any API is
403 Requests from this Android client application <empty> are blocked.
I'm calling the APIs by using a Cloud Endpoints generated client lib, and I've not been able to find any method that I can use at initialisation time to set the app credentials, nor does it do it by itself (as I can guess from the "<empty>" in the error).
I can't find any useful info in any documentation as well, as far as I've red it seems like it should do it by itself.
This is my init code:
MyApi.Builder builder = new MyApi.Builder(new NetHttpTransport(), new AndroidJsonFactory(), null)
.setApplicationName("<my package name>")
.setRootUrl(<my root URL>)
.setGoogleClientRequestInitializer(new MyApiRequestInitializer(<my API key>));
I've also tried what suggested in this answer but nothing changed.
Is there any passage I'm missing? How should it be done?
I believe the problem appears only in emulators. I am getting the same error when running my app in an emulator. However, on real devices I do not seem to have the problem. Have you tested it on a real device?
Using the Mobile Backend Starter (MBS) Android classes (those distributed as a sample project when creating a new project in Google Dev Console and demoed at Google I/O 2013) I'm able to insert new entities to the cloud datastore via calls to CloudBackendMessaging.insertAll or .updateAll. The latter will create entities if none exist so seems functionally identical to insert for new records.
The insertion/creation works fine. However when I attempt to update existing entries in the datastore, I received permissions errors e.g. (from the backend log)
Method: mobilebackend.endpointV1.updateAll
Error Code: 401
Reason: required
Message: Insuffient permission for updating a CloudEntity: XXXXXX by: USER: YYYYYYY
which results in a matching access error in the logcat client side.
In all cases I am using Secured access authenticating with a valid Google account (my own).
The entities being inserted are thus showing as "owned" by my user ID with "updated by" and "created by" showing my Google account's email address.
However when the update of the existing record is made, using exactly the same CloudBackendMessenger object and thus same credentials etc. the backend is telling me I can't update due to permissions issues. But surely if I just made the entity with the same credentials this can't be correct? Looking at the documentation it appears that I should be able to edit entities owned by the same user ID in all cases (regardless of the KindName and whether it is prepended [public], [private] or nothing).
Can anyone who has received permissions errors on UPDATES via Mobile Backend Starter for Datascore please shed any light? I have been banging my head over this for most of today.
I've faced the similar error "Insuffient permission for updating a CloudEntity" when using cloudBackendAsync.update(cloudEntity). I resolved it by making sure the cloudEntity has it's createdAt field set. createdAt is autogenerated and I think I am not supposed to touch it. But it worked for me. In my case I am first obtaining list of cloud entities. This is when I get createdAt field of cloud entities. Then when I am updating I setting the createdAt field from previously obtained entities.
Edit: Had to do similar thing for owner field also.
Similar to one of the comments above, I successfully got around this by getting the original CloudEntity before doing the insert/update/delete function.
CloudQuery cq = new CloudQuery("datastoretype");
cq.setLimit(1);
cq.setFilter(Filter.eq("_id",id));
cloudEntity.setId(id);
mProcessingFragment.getCloudBackend().get(cloudEntity, handler);
Thereafter it was trivial to do the following:
mProcessingFragment.getCloudBackend().update(cloudEntity, handler);
The docs definitely ought to be more clear on this, whether it is a strict requirement or bug.
The answers posted so far work around the problem if you don't mind all users being able to access the entity you are trying to update. However, a better solution that retains the access permissions is detailed by google here - https://cloud.google.com/cloud/samples/mbs/authentication
If you want to pass the user’s Google Account info to the backend on
each call, use the CloudBackend#setCredential() method (also available
on the subclasses, CloudBackendAsync and CloudBackendMessaging) to set
a GoogleAccountCredential object before calling any Mobile Backend
methods.
GoogleAccountCredential credential = GoogleAccountCredential.usingAudience(this, "<Web Client ID>");
credential.setSelectedAccountName("<Google Account Name>");
cloudBackend.setCredential(credential);
Setting credientials enables the client to operate when the backend is
in “Secured by Client ID” mode and also sets createdBy/updatedBy/owner
properties of CloudEntity automatically.
Problem with the new App engine connected android application projects for the google eclipse plugin? This is the "Big Daddy" sample shown at goolge i/o 2011. My sample project compiles and the android app appears to work fine and registers with the server. However when I send a message from the server I get the following: Having issue with sample project. Android appears to work fine and registers with the server and the c2dm server, however I cannot send a message.
Also of note on the server is a c2dmconfig datastore object. It has fields for authToken and c2dmUrl. The authToken has a token, however the c2dmUrl is NULL. I suspect this is where my problem lies, but not sure how to fix it.
Thanks Patrick
I found this question by wondering the same thing, if the c2dmUrl being null is a problem. It would seem that this is not an issue though. If you look at the C2DMConfig (the entity that you are referencing), there is a function called "getC2DMUrl". Here it is:
public String getC2DMUrl() {
if (c2dmUrl == null) {
return DATAMESSAGING_SEND_ENDPOINT;
} else {
return c2dmUrl;
}
So null is a supported value for this. If a specific URL isn't specified, it simply returns it to the default.