iphone - data signing using NSData of the private key - iphone

I am working on a e-banking iphone application.
I am using WSS with XML-Signature to sign the requests to the customer's SOAP server.
Since the iPhone device can not be trusted (due to jail-breaking), the customer
requirement is to manually encrypt the RSA key pair (using AES128) before storing the keys into keychain.
From what I have found so far, the keys are automatically added to the keychain when generated.
So my idea is to extract the data afterwards (the same way the public key is extracted in the CryptoExercise example), remove the keys from keychain, do the AES encryption and store it again into keychain as a custom NSData.
1) Do you see any problem with this ?
I read somewhere that retrieving the data or deleting the key might require some sort of password, although I didn't got what password. I will try this later today and will post the answer if no answer is posted in meantime :)
2) I can not find if there is any way to use this key without implementing some more hacks in the code?
It seams like the SecKeyRawSign method only accepts a SecKeyRef reference which is a pointer to the key in keychain. Is there some other method for signing using the NSData of the key ?
The only idea I have in the moment is to use SecItemAdd method to add the non-encrypted key into the keychain before signing, and remove it after signing. But I don't like this since it will happen all the time, and if the application is shut down (crashes or something) before the key is removed from keychain it will remain there until lets say the next time application is started.
Any idea for a better solution ?
regards

Consider checking Apple example and documentation for Security. Framework:
https://developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/CertKeyTrustProgGuide/iPhone_Tasks/iPhone_Tasks.html#//apple_ref/doc/uid/TP40001358-CH208-SW13 - see this link

Related

Create an RSA key with unexportable private key

I want to create and save an RSA key inside the iOS Keychain, I know how to do it but I wonder if it is exportable or not?
I've also read the apple documentation about the Secure Enclave and I know it is the securest way to save a key but it only supports EC keys so I have to use Keychain.
base on Secure Enclave document:
Keeping a private key in a keychain is a great way to secure it. The key data is encrypted on disk and accessible only to your app or the apps you authorize. However, to use the key, you must briefly copy a plain-text version of it into system memory. While this presents a reasonably small attack surface, there’s still the chance that if your app is compromised, the key could also become compromised.
So we can assume that there is the possibility of compromising.
Now my question is that:
Is it possible to export the private key from the Keychain while we are creating it inside it?
If it is, how can I have an RSA key with unexportable private key?

Flutter - Why/How is flutter_secure_storage secure?

I think I don`t understand this mechanism at all.
You are supposed to create it by setting a key value, but if someone decompiles the flutter code and reads it again with flutter_secure_storage, doesn't it all show up?
https://pub.dev/packages/flutter_secure_storage
The documentation explanation is too short. I want to keep my private key safe. Anyone could tell me more about this issue & mechanism??
PLUS
I just set the key value, but realized that the key value is not visible on other phones. If this happens, the cell phone has to expose the private key every time the app is opened for the first time... I don't know why this is secure.
Note the difference between a cryptographic key and a map key. The key you provide to the flutter_secure_storage api is more akin to a label, one you use to find the correct value to retrieve. The cryptographic key is provided/handled by the library together with the device KeyStore, and as such is typically only available after the user unlocks with a biometric prompt (fingerprint etc.).

Difference between SecPKCS12Import and storing certificate as NSData in keychain?

I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:
Get the Cert via email or AppConfig
Store the Cert (securely)
Extract Identity and Trust from the Cert.
Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.
Turn Identity and Trust into the auth response challenge.
My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().
But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.
The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?
The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly
I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:
The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.
Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.
Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy

Using encryption in save data to avoid cheating in an iPhone game

I've read the Apple export restrictions for app using encryption and I'm baffled.
Is it worth to do all the CCATS / SNAP-R procedure only for encrypting my gamesave data?
Using encryption will prevent my app to be sold in some region?
Can my app be rejected because of encryption?
Thanks!
In my opinion it is not worth using encryption. A simple checksum can do pretty much the same.
Instead of encrypting your savegames you could calculate a checksum to detect if someone tried to change the savegame.
I agree with #pre, skip the encryption part and use HMAC (on ios) to make sure that your saves were not altered. To protected the HMAC secrete I would generate it using any random generator and store it in the keychain.
Keychain entries are not backed up so it is hard to read them if your iphone is not jailbroken. You can try this wrapper around keychain: https://github.com/carlbrown/PDKeychainBindingsController
The registration process is not that difficult. Most of it is filling out company info (name,address, etc.). There is only one part that asks you about your encryption. The process takes about 3 days and a few back-and-fourths.
Apple has the checkbox in iTunesConnect to mark if you use encryption for anything other than sign-in credentials. It appears like they are just covering their butts. You submit a screenshot of your completed form and they sign off on it right away.
For an outline of the steps you need to take see:
https://www.chatmap.io/blog/iPhone-iTunes-ERN-Encryption.php
In short, it's not a great deal of work to register.

iPhone and handling secure key delivery

We're writing an iPhone iOS4 app which contains an SQLite database which is encrypted and needs a key to be read. The database contains data supplied to the developer, it does not contain any user data.
The problem we have is how to negotiate delivering a key and/or whether/where to keep the key on the device when it arrives. This would be done without any interaction from the user.
Is there a way to safely put a key in and request a key from the keychain at runtime so that if, for example, the app ends up on a jail broken device the key can not be extracted by an evil person?
I have doubts this can all be done securely but I'm not an expert here. For example, some where in the source code we would need to request the key from the keychain.
Thanking you kindly in advance for your thoughts.
When you say 'key' do you mean a key in string format? If so, then yes place it into the keychain. SHFFKeychainUtils provide an easy interface to storing string values into the iOS keychain.
The best way to do this is to request a key from the user at app start, and then use that NSString to encrypt the database (or store it into the keychain for a hassle-free launch).