Encryption keys for custom cryptography

Overview of encryption keys for custom cryptography

The -derivedAppKeyWithIdentifier:error: method

The -derivedSharedKeyWithIdentifier:error: method

Error returns for derived key methods

Deprecated custom cryptography methods

Overview of encryption keys for custom cryptography

The AppConnect library provides methods to obtain keys useful for cryptographic operations. It can provide two types of keys:

App keys, which are keys that are specific to your app on the device

Shared keys, which are keys that are shared among all AppConnect apps on the device

If your app requires cryptography but the AppConnect secure file I/O APIs are not sufficient, it can use an app key with custom cryptographic routines. For example, consider an app that currently relies on the iOS keychain for secure storage. The keychain is not secure if the device lacks a device passcode. Refactoring the app to use the secure file I/O APIs is possibly prohibitively difficult. Therefore, instead of refactoring, you can add code to encrypt data being stored in the keychain, and you can use an app key as the encryption key.

If your app shares encrypted data with another AppConnect app, you can use a shared key as the encryption key.

Use one of the following methods, which are on the AppConnect singleton object:

-(nullable ACSensitiveData *)derivedAppKeyWithIdentifier:(NSString *)identifier 
                error:(NSError **)error;
 
-(nullable ACSensitiveData *)derivedSharedKeyWithIdentifier:(NSString *)identifier 
                error:(NSError **)error;

If successful, these methods return an ACSensitiveData object containing a 32-byte key. These methods are successful only when secure services are available.

Securing sensitive data such as encryption keys

The -derivedAppKeyWithIdentifier:error: method

The -derivedAppKeyWithIdentifier:error: method derives an encryption key. This “app key” is unique to this instance of your app. Calling this method with the same identifier in an instance of your app on a different device derives a different app key.

The app key is based on the following:

the app

the identifier passed as an argument

The identifier is any string. Use a different identifier for each encryption purpose. For example, if your app uses AES, SHA-1, and HMAC routines, use a different identifier for each. Reusing an identifier for different encryption purposes weakens the key, making it more vulnerable to brute force attacks.

a secure services seed

Each device has one secure services seed, which is generated by the Ivanti client app. The seed is lost if the device user deletes the Ivanti client app, or the Ivanti server retires the device. The Ivanti client app does not back up the seed, so a backup and restore of the device will also cause the seed to be lost.

The -derivedSharedKeyWithIdentifier:error: method

By using the shared key provided by this method, more than one AppConnect app on the same device can share encrypted data. For example, one AppConnect app can encrypt data using a derived shared key created with a particular identifier. Another AppConnect app can then use the same identifier to get the shared key, and decrypt the data with the shared key.

The -derivedSharedKeyWithIdentifier:error: method derives an encryption key based on the following:

the identifier passed as an argument

a secure services seed

Each device has one secure services seed, which is generated by the Ivanti client app. The seed is lost if the device user deletes the Ivanti client app, or the Ivanti server retires the device. The Ivanti client app does not back up the seed, so a backup and restore of the device will also cause the seed to be lost.

Error returns for derived key methods

When unsuccessful, the -derivedAppKeyWithIdentifier:error: and -derivedSharedKeyWithIdentifier:error: methods return an NSError object as shown in the following table:

Table 18.   NSError objects returned by derived key methods

NSError domain

NSError code

Description

ACErrorDomain

ACErrorNoKeys

Secure services are not available.

ACErrorDomain

ACErrorInvalidArg

The identifier argument is nil or has zero-length.

The NSError domain and code values are defined in ACError.h.

Deprecated custom cryptography methods

The following methods are deprecated.

The -derivedAppKey:withIndex: method (deprecated)

The -derivedSharedKey:withIndex: method (deprecated)

Ivanti recommends you use instead the -derivedAppKeyWithIdentifier:error: and derivedSharedKeyWithIdentifier:error: methods.

The -derivedAppKey:withIndex: method (deprecated)

The -derivedAppKey:withIndex: method derives an encryption key. This app key is unique to this instance of your app. Calling this method with the same index in an instance of your app on a different device derives a different app key.

The app key is based on the following:

the app

the index passed as an argument

The index is any string. Use a different index for each encryption purpose. For example, if your app uses AES, SHA-1, and HMAC routines, use a different index for each. Reusing an index for different encryption purposes weakens the key, making it more vulnerable to brute force attacks.

a secure services seed

Each device has one secure services seed, which is generated by the Ivanti client app. The seed is lost if the device user deletes the Ivanti client app, or the Ivanti server retires the device. The Ivanti client app does not back up the seed, so a backup and restore of the device will also cause the seed to be lost.

The -derivedSharedKey:withIndex: method (deprecated)

The -derivedSharedKey:withIndex: method derives an encryption key based on the following:

the index passed as an argument

a secure services seed

Each device has one secure services seed, which is generated by the Ivanti client app. The seed is lost if the device user deletes the Ivanti client app, or the Ivanti server retires the device. The Ivanti client app does not back up the seed, so a backup and restore of the device will also cause the seed to be lost.

By using a shared key, more than one AppConnect app on the same device can share encrypted data. For example, one AppConnect app can use a derived shared key with a particular index to encrypt data. Another AppConnect app can then get the same derived shared key by using the same index to decrypt the data.