Develop Reference

Generate CMSSignedData with no private key in JAVA

I'm currently trying to generate a CMSSignedData using only a certificate data and a signed data which is generated from an external software (so I don't have access to the private key and the signature generation is transparent for me). What i need is the encoded data to add it to a SMIME signature content.
Searching on web I find out a solution with BouncyCastle that uses the private key and the data to be signed to get a CMSSignedData. But it don't fix to my problem because I don't have access to private key and the signature is already generated.
Is there any way to create a CMS object using only the certificate data, the public key and the previously generated signature?
Any approach or library i can use or try?

CMS (Cryptographic Message Syntax) is specified in RFC 5652. The SignedData type is an ASN.1 structure, which basically consists of the signed data (encapContentInfo), the signature certificate (and chain) and the signature itself (part of signerInfos):
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
So, what you have to do now is to create this ASN.1 structure out of the data you have. If you don't already know the algorithms that were used for the signature, you can certainly obtain that information from the operator of the external signing software.
Bouncy Castle is generally a good choice for ASN.1 encoding and in addition you can use the source code of Bouncy Castle that normally creates a CMSSignedData object (CMSSignedDataGenerator) as a template.

Import encrypted AES key into Android Keystore and store it under new alias

I am just familiarizing myself with the Android Keystore API.
I found out that the following features are available:
At least on some devices the Android Keystore is hardware backed, meaning that crypto operations run in a secure environment (TEE).
When the keystore is hardware backed, private RSA keys as well as secret symmetric keys that have been created within the Keystore can
be configured to never leave the Keystore and the raw keys cannot be
read out even with root access.
I am wondering now if the following is possible:
Generate a Public/Private key pair where the private key never leaves the Keystore
Upload the public key of this pair to a server
On the server: create a random symmetric AES key and encrypt it with the public RSA key uploaded by the user
On the device: Download this encrypted AES key
Import it into the hardware backed Keystore such that it is decrypted in there with the private key of the pair and stored under a
new alias
Use this new key alias to perform symmetric encryption and decryption
1-4 should be possible, the missing link for me now is point 5. in this list. Can some one help me out and tell me if this is possible at all and/or point me to the correct API reference?
I found this:
https://android.googlesource.com/platform/development/+/master/samples/Vault/src/com/example/android/vault/SecretKeyWrapper.java
But it looks to me as if the unwrapping of the secret key happens in the normal environment and the decrypted AES key would be available in the App, which would not satisfy my security requirements.
Update:
I created a small test project using the linked SecretKeyWrapper and here are two code snippets:
The first one does the following:
Create a random AES key (not within in the keystore, this is what would happen on a server later). Obviously the raw key can be retrieved from the generated SecretKey object what isn't a problem since the server can know the key.
Encrypt/wrap the key with a RSA public key that was created in the client's Android Keystore (this would also happen on a server).
Decrypt the key again with the RSA private key (this would happen on the client and actually happens within the TEE in the example).
Snippet 1:
SecretKeyWrapper secretKeyWrapper = new SecretKeyWrapper(this,"testKeyRsa");
// Generate a random AES key (not in the keystore) [1]
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(128);
SecretKey secretKeyGenerated = keyGen.generateKey();
byte[] secretKeyGeneratedRaw = secretKeyGenerated.getEncoded();
// wrap this key with the RSA key from the keystore [2]
byte[] wrappedKey = secretKeyWrapper.wrap(secretKeyGenerated);
// unwrap it again with the RSA key from the keystore [3]
SecretKey unwrappedKey = secretKeyWrapper.unwrap(wrappedKey);
// the raw key can be read again [4]
byte[] unwrappedKeyRaw = secretKeyGenerated.getEncoded();
What I want to achieve is that the unwrapped key from [3] is stored in the Keystore with a new alias without returning the raw key. Of course I could easily import the SecretKey object into the Keystore here, but the problem is, that at this point the raw key can be retrieved from the object with the statement [4] what induces a security flaw. It is clear that the unwrapping/decryption already happens in the Keystore/TEE, since the private RSA key that is used for the decryption lives in the Keystore and cannot be retrieved.
If I compare this to the situation where a random secret AES key is created in the keystore, I notice that different types (implementing the SecretKey Interface) are returned. In the above example, the type is SecretKeySpec, whereas for keys which are returned from the Android Keystore (see snippet 2 below), "opaque" types are used where the getEncoded() method always returns null. In the following example, the type of keyAesKeystore is AndroidKeyStoreSecretKey.
Snippet 2:
// create a new AES key in the keystore
KeyGenerator keyGenAndroid = KeyGenerator.getInstance("AES","AndroidKeyStore");
keyGenAndroid.init(
new KeyGenParameterSpec.Builder("testKeyAes",
KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.build());
SecretKey keyAesKeystore = keyGenAndroid.generateKey();
// this returns null
byte[] keyAesKeystoreRaw = keyAesKeystore.getEncoded();
So to rephrase the question: Is it somehow possible to securely import a RSA wrapped AES key into the Android Keystore without revealing the secret key to the application?
Update 2:
#Robert makes the absolutely valid in the answer below that it actually does not matter if the unwrapping happens in the TEE or in the Rich OS (App) since the App (or a tampered version) could always later (after intercepting the wrapped key) just "use" the private RSA key from the Keystore to unwrap the AES key (without the need to access the raw private key at all).
Here is another thought though:
I found that it is possible to set Key Protection Parameters for keys in the Android Keystore (see here).
The linked implementation for the SecretKeyWrapper does not use such protection parameters. After changing the generateKeyPair method as follows and adding the PURPOSE_DECRYPT and PURPOSE_ENCRYPT properties everything still works.
private static void generateKeyPair(Context context, String alias)
throws GeneralSecurityException {
final Calendar start = new GregorianCalendar();
final Calendar end = new GregorianCalendar();
end.add(Calendar.YEAR, 100);
final KeyGenParameterSpec keyGenParameterSpec = new KeyGenParameterSpec.Builder(alias, KeyProperties.PURPOSE_ENCRYPT)
.setDigests(KeyProperties.DIGEST_SHA256, KeyProperties.DIGEST_SHA512)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_PKCS1)
.build();
final KeyPairGenerator gen = KeyPairGenerator.getInstance("RSA", "AndroidKeyStore");
gen.initialize(keyGenParameterSpec);
gen.generateKeyPair();
}
I can now protect the RSA key such that it cannot be used for decryption by removing the PURPOSE_DECRYPT property. As expected the Cipher.unwrap method stops working and throws an Incompatible purpose exception then.
So what I would need then is a protection property where the plain decrypt functionality is blocked but which allows such a "secure import functionality" I am looking for. Something like a "PURPOSE_IMPORT" which apparently does not exist.

What you're looking for now exists, as of API level 28 (Android Pie). To use you you need to:
Create a wrapping key pair, an RSA key pair with purpose PURPOSE_WRAP_KEY. You should also generate an attestation for the public key to verify that the private key is a keystore key, in secure hardware.
Send the public key (and attestation) from your app to the server that will provide the wrapped symmetric key.
On the server, you need to wrap the symmetric key. This involves more than just encrypting it, because the wrapper needs to contain not just the key material but also the authorization list that defines how the key may be used. This is done by packaging the key and authorization info in an ASN.1 DER-encoded structure, per the schema documented here. There's some sample wrapping code in the CTS test. Note that if this format seems excessively complicated (e.g. the optional "masking key"), it's because in a future Android release there will be a corresponding secure export function and the use cases for that require the additional complexity. The secure export function didn't make it into Q, but will probably make it into R.
Send the wrapped key to the app, which must create a WrappedKeyEntry and use Keystore.setEntry() to store it.
This should work on any device with API level 28. However, if the device has a Keymaster version < 4 (see the attestation certificate to find out what version of Keymaster is present), then the unwrapping operation will return the wrapped key material to Android userspace. Keymaster version 4 (or above) will keep the unwrapped material in secure hardware, but because lower versions don't have support for the wrapped key feature, it has to be sort of emulated.
What happens if you have a lower Keymaster version is that when you create a PURPOSE_WRAP_KEY key pair, what is actually requested of the secure hardware is a PURPOSE_DECRYPT key pair. Then when you do the import, the keystore daemon uses this PURPOSE_DECRYPT private key to decrypt the secret from the wrapper, then it imports the secret into the secure hardware and wipes the userspace memory that held it. So, the key material exists in the keystore daemon's memory for a fraction of a millisecond. Again, if the device has Keymaster version 4+ it is only unwrapped inside the secure hardware and never leaves.

What you want to achieve is not possible by simply using the AndroidKeystore. What you need is custom code that runs within the TEE.
The reason for this is simple: When you have set-up your app with an asymmetric key-pair stored in the AndroidKeystore and you receive the wrapped AES key it does not matter if the unwrapping takes place inside or outside the AndroidKeystore:
All keys of an app stored in the AndroidKeystore are usable by the app in the normal environment. Is is by design as you wouldn't be able to use them otherwise.
Hence if the asymmetric key-pair is usable by the app the app is always able to unwrap the received wrapped AES key (using code in the normal environment). Therefore it does not make any difference where the unwrapping takes place. You can not guarantee that someone had copied the wrapped AES key when the app received it and then unwrapped it using the asymmetric key from the AndroidKeystore.

Create a .jks file from a Certificate and private Key

I wanted to create a .jks file using a Certificate and a private Key from an etoken programmatically.
I could access the etoken using the password but could not read the Certificate or the private key.
In an earlier question I had asked whether the private Key could be extracted from the etoken for which I was told it was not possible.
So, my question is whether I could get the reference of the private key using PKCS11..
Thank you.

You can get the reference (object handle) of the PrivateKey using PKCS11. You can even get the public components of the PrivateKey. But you cannot extract the sensitive data that comprises the key.

BouncyCastle: Extract public key informationfrom Certificate Signing Request

I am using Bouncy Castle library in Java for reading CSR. I need to extract the public key information from CSR. I can see that openssl is able to extract required information from CSR.
I can't find any way to do this in BouncyCastle. I have been able to read PKCS10CertificationRequest object from the CSR. I have seen examples using SubjectPublicKeyInfo for extracting public key. But the code relies on the fact that algorithm of public key is already known. I can do a "instanceof" operation for various algorithm parameters and match but I think there would be something better. I want to derive the algorithm from CSR itself. I tried to find this information but couldn't find anything related to this.
Thanks for help.

Solution is to create a new wrapper around the PKCS10CertificateRequest like this:
JcaPKCS10CertificationRequest jcaCertRequest =
new JcaPKCS10CertificationRequest(pkcs10CertRequest.getEncoded()).setProvider("BC");
This class has the getPublicKey() method.
PublicKey publicKey = jcaCertRequest.getPublicKey();

Parsing certificates with bouncycastle

I'm a certificate noob. I've been trying to import certificates for the past couple of hours and the more I dig into security stuff, the more it feels impossible to understand.
Here is what I'm trying to achieve in java:
the user can upload any kind of formatted certificate with an optional passphrase
I need to convert the certificate to a non-binary PEM format
Extract the private and public keys to store in a database, throw error if missing one of the two
So far I've been able to parse some certificates using java security's x509Certificate but I can't get the private key. I've also tried bouncy castle but no success there either.
Thanks for your help

An X509Certificate only contains a public key.
Private keys are usually encoded using PKCS#8. Try KeyFactory with a PKCS8EncodedKeySpec.
Combined public key certificates with private keys are usually encoded using PKCS#12 (.pfx, .p12). Try a KeyStore of "PKCS12" type (with Bouncy Castle as provider).