ibm security trusteer mobile sdk: iospublic.dhe.ibm.com/.../pub/certify/ibm...guide_ios.pdf ·...

IBM Security Trusteer Mobile SDK: iOS Developers Guide

Version 5.2

December 2014

Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 19-21, Nihonbashi-Hakozakicho, Chuo-ku Tokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

IBM Security Trusteer Mobile SDK: iOS | ii Developers Guide Version 5.2 Copyright 2014 IBM Corp.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject to change before the products described become available.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

Copyright License

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. 2004, 2014. All rights reserved.

If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.

Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

IBM Security Trusteer Mobile SDK: iOS | iii Developers Guide Version 5.2 Copyright 2014 IBM Corp.

Privacy Policy Considerations

IBM Software products, including software as a service solutions, ("Software Offerings") may use cookies or other technologies to collect product usage information, to help improve the end user experience, to tailor interactions with the end user or for other purposes. In many cases no personally identifiable information is collected by the Software Offerings.

For more information about the use of various technologies, including cookies, for these purposes, see the "IBM Software Products and Software-as-a-Service Privacy Statement" at http://www.ibm.com/software/info/product-privacy.

IBM Security Trusteer Mobile SDK: iOS | iv Developers Guide Version 5.2 Copyright 2014 IBM Corp.

Contents

Notices ii

Copyright License iii

Trademarks iii

Privacy Policy Considerations iv

1. Front Matter 1

1.1. About this Publication 1

1.2. Support Information 1

1.3. Accessibility 1

1.4. Statement of Good Security Practices 2

2. General Architecture 3

3. Quick Start 4

3.1. Step 1: Plan Integration with the Library 4

3.2. Step 2: SDK Installation 4

3.3. Step 3: Configure Your Build System 5

3.4. Step 4: Add Library Initialization and Finalization Calls 6

3.5. Step 5: Configure Library Background Tasks 8

3.6. Step 6: Create the Application Security Manifest 8

3.7. Step 7: Obtain Device Risk Assessment Information 8

4. Foundations of Using the Library 10

4.1. Calling TAS API 10

4.2. Initialization and Finalization 10

IBM Security Trusteer Mobile SDK: iOS | v Developers Guide Version 5.2 Copyright 2014 IBM Corp.

4.2.1. Initialization Flags 11

4.3. Background Operations 11

4.3.1. Manual Governed Mode 12

4.3.2. Autonomous Mode 13

4.4. Multithreading Issues 13

4.5. Error Reporting 13

4.6. Security Manifest 13

5. Using Device Risk Assessment 16

5.1. Obtaining the Risk Assessment Object 16

5.2. Querying Risk Assessment Factor Results 16

5.3. Controlling Device Risk Information Calculation 17

5.4. Risk Factor Definitions 18

6. Using SSL Certificate Validation 19

6.1. Configuring the SSL Certificate Validation 19

6.2. Validating an SSL Certificate 20

7. Using the Device Key 21

8. Security Best Practices 22

8.1. Application Flow 22

8.2. Encryption of Strings in the SDK 22

8.3. Obfuscation and Symbol Stripping: 23

9. Malware ID Numbers 24

IBM Security Trusteer Mobile SDK: iOS | vi Developers Guide Version 5.2 Copyright 2014 IBM Corp.

10. Testing on an iOS Device 25

10.1. Cydia Repository 25

10.2. Testing Jailbreak Detection 26

10.3. Testing Malware Detection 26

11. IBM Security Trusteer Mobile Risk Engine 27

11.1. System Flow 27

11.2. Device Data Collection 28

11.2.1. Permanent User/Account Identifier 29

12. Advanced Configuration 31

12.1. Changing the Configuration Update Host Server 31

12.2. Communication Using a Proxy 32

12.2.1. Testing Communication with the Proxy Server 32

13. Phone Gap 34

13.1. Using PhoneGap with iOS 34

13.2. Mobile SDK API 34

14. Risk Score Output 35

14.1. Risk Score Output Examples 35

15. Device Key Creation 37

16. Minimizing External Communication 38

17. IBM Worklight Integration 39

18. Mobile SDK Checklist 40

IBM Security Trusteer Mobile SDK: iOS | vii Developers Guide Version 5.2 Copyright 2014 IBM Corp.

1. Front Matter

1.1. About this Publication

This document provides information on using the IBM Security Trusteer Mobile SDK

("Mobile SDK") which is a library designed to provide application security services to

mobile applications.

The following link provides information about which operating systems are supported

for apps created by the Mobile SDK:

http://www.trusteer.com/support/supported-platforms

For information on the Mobile SDK version release process, refer to the IBM Security

Trusteer Mobile SDK Version Release Process document.

1.2. Support Information

For support information, refer to our Support website:

http://www.trusteer.com/support

1.3. Accessibility

Accessibility features help users with a disability, such as restricted mobility or limited

vision, to use software products successfully. With this product, you can use assistive

technologies to hear and navigate the interface.

IBM Security Trusteer Mobile SDK: iOS | 1 Developers Guide Version 5.2 Copyright 2014 IBM Corp.

http://www.trusteer.com/support/supported-platforms

http://www.trusteer.com/support

1.4. Statement of Good Security Practices

IT system security involves protecting systems and information through prevention,

detection and response to improper access from within and outside your organization.

Improper access can result in information being altered, destroyed, misappropriated

or misused or can result in damage to or misuse of your systems, including for use in

attacks on others. No IT system or product should be considered completely secure

and no single product, service or security measure can be completely effective in

preventing improper use or access. IBM® systems, products and services are designed

to be part of a comprehensive security approach, which will necessarily involve

additional operational procedures, and may require other systems, products or

services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS,

PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ORGANIZATION

IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.


2. General Architecture

The Trusteer Mobile Application Security (TAS) library is implemented as either a static

or dynamic link library. An authorized host application links this library in a platform-

specific manner (as detailed below for different platforms). Once the library is linked

with a host application, the application can invoke library API calls to control

application security. The application needs to invoke at least the library’s initialization

API call on startup for the library to function properly.

The TAS library is available on a variety of mobile platforms. The library’s API and

underlying functionality is preserved among platforms, with the minimal necessary

adjustments such as API mapping to different programming languages.

In addition to linking with the library and invoking a minimal set of initialization and

finalization APIs, the mobile host application is also embedded with an application

security manifest --- defining a security policy enforced by the library. This manifest is

loaded by the library and used to configure it on initialization.

The core functionality provided by the library is as follows:

Device risk assessment. Risk assessment may be based on a variety of

indicators such as modified firmware/OS that may circumvent device built-in

security mechanisms, user security settings, presence of suspicious software on

the device, and network reputation. The exact calculation of risk assessment is

controlled by configuration received from IBM servers and updated

periodically by the library.


3. Quick Start

The following paragraphs provide a quick-start guide to using the Mobile SDK to

secure your mobile application. You can also refer to a TAS sample application to see

how the TAS can be integrated into an application. Please contact your IBM

representative to receive a sample application.

3.1. Step 1: Plan Integration with the Library

We recommend planning the integration of the Mobile SDK before starting to

implement it, following this checklist:

Verify that your application’s target platform is supported by Mobile SDK.

Decide how risk assessment will be used by your application.

When should risk assessment be queried?

What should be done with risk assessment results?

Plan code changes required to integrate the library.

Identify library initialization / finalization call spots.

Decide on background tasks policy --- whether you want to allow the library

to manage background tasks by itself (recommended) or you wish your

application to schedule them.

3.2. Step 2: SDK Installation

Unzip the provided installation package to a designated folder on your development

system. It is recommended that you also add an environment variable named

TAS_ROOT to your system, which points to this folder.


3.3. Step 3: Configure Your Build System

Configure the build system for your software to link to the Mobile SDK.

Using XCode:

1. Add directory $TAS_ROOT/platform/ios/include to the "Header

Search Paths" (HEADER_SEARCH_PATHS) build setting, where $TAS_ROOT

is the folder into which you have unzipped the installation package. This needs

to be done either at the XCode project top level, or for each target you intend

to use the library with.

2. Set your target to link to the following static libraries from $TAS_ROOT/

platform/ios/lib:

libtas.a

libssl.a

libcrypto.a

libcares.a

libtommath.a

libtomcrypt.a

This can be done by secondary-clicking the "Link Binary With Libraries" node of

required targets, choosing Add | Existing Files… from the context menu, then

selecting the library files above.

If you are already using a different version of libssl.a, libcrypto.a or libcares.a, it

is possible to use a different SDK library that does not require the above

libraries as separate libraries. To do so, only copy the following library instead

of the previous list:

libtas_full.a

3. Be sure to link your target against the following platform libraries:

libz.dylib

Foundation.framework

CFNetwork.framework


Security.framework

Libstdc++.dylib

SystemConfiguration.framework

CoreMotion.framework

This can be done by secondary-clicking the "Link Binary With Libraries" node of

required targets, choosing Add | Existing Frameworks… from the context

menu, then selecting the libraries above.

4. Add the TAS default configuration file as a resource to your project. A version

of the TAS default configuration file is provided in the library. This should be

taken from

$TAS_ROOT/platform/ios/default_conf/default_conf.rpkg

and added as a resource to the application. The resource should be saved under

the tas folder in the project folder.

Please verify that the "Copy Bundle Resources" phase contains the 'tas' folder

and that after the build the actual folder and files are found in the target device

or build product inside the .app container, e.g.:

MYAPP.app/tas/default_conf.rpkg

3.4. Step 4: Add Library Initialization and Finalization Calls

According to the plan from Step 1 above, add the calls to initialize and finalize the

library --- call TasInitialize() on startup and TasFinalize() when shutting

down.

Before calling TasInitialize(), setup a TAS_CLIENT_INFO struct with the

vendor ID, client ID and client key. You need to pass a pointer to this struct to

TasInitialize().

Refer to Initialization and Finalization for more information.


The Vendor ID, Client ID and Client Key are provided to you from IBM in a license file,

such as the following example:

TAS License Details =================== Vendor ID: YourBankHere.com Client ID: YourBankHere.bankingapp Client Key: ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234AB

The following is example code for initializing the library:

#include "taslib.h" TAS_CLIENT_INFO client_info = { sizeof(TAS_CLIENT_INFO), "YourBankHere", // Replace with Vendor ID "YourBankHere.bankingapp", // Replace with Client ID NULL, ”ABCD1234…” //Replace with Client Key }; if(TasInitialize(&client_info, NULL, 0) != TAS_RESULT_SUCCESS) { // ... add error handling here. }

Note: The client key that you receive from IBM is inserted into the above code in the specified location. This key is plain text, but there is no risk involved in exposing this key as it only contains public information. When downloading a configuration from the update site, the key allows IBM to identify the customer and deliver the appropriate configuration.


3.5. Step 5: Configure Library Background Tasks

On initialization you may specify to TasInitialize() whether you wish to allow

the library to automatically perform background tasks such as updating the

configuration, known as Autonomous mode, or if you would like to explicitly indicate

to the library when it is permitted to perform these tasks, known as Manual Governed

mode.

Note: The tasks (configuration update and risk analysis) only run as part of the background operations if the SDK decides they are necessary.

Refer to Background Operations for more information.

3.6. Step 6: Create the Application Security Manifest

The application security manifest is a compiled encrypted file that contains static

configuration of the Mobile SDK. You can start with one of the manifest templates

provided and edit it to fit your needs. The template you should use is:

$TAS_ROOT/platform/ios/default_manifest

Once your manifest is ready, compile it using the manifest compiler found in

$TAS_ROOT/tools/tmc.jar and add the resulting file to your project:

As a resource named tas/manifest.rpkg.

For more information on the manifest, refer to Security Manifest.

3.7. Step 7: Obtain Device Risk Assessment Information

Invoke TasDraGetRiskAssessment() to obtain a risk assessment object handle.

Use this handle to query for risk assessment information using

TasGetRiskAssessmentItemByName(). Finally, once done querying, release

the risk assessment object handle using TasDraReleaseRiskAssessment().


The risk assessment is periodically calculated in the background (either autonomously

or governed by the application --- see above). Different risk items are updated in

different intervals. When querying for risk item data, the returned information includes

the last time of calculation. It is recommended that the application inspect the risk

assessment several times during runtime (for instance, with each transaction) in order

to obtain updated risk assessment information.

If you wish to force a recalculation of all items before querying them, use

TasDraRecalcRiskAssessment() with the TAS_DRA_FORCE_RECALC

option. Note that recalculation may take a long time, so it is recommended not to

block the application while performing this.

Refer to Using Device Risk Assessment for more information.


4. Foundations of Using the Library

4.1. Calling TAS API

All of the TAS API functions return a TAS_RESULT value. It is the developer’s

responsibility to monitor the return codes. A successful call should return

TAS_RESULT_SUCCESS.

A description of the API functions and objects can be found in the IBM Security Trusteer

Mobile SDK API Reference Guide or in the TAS package by opening the index.html in the

docs\html directory.

Note: As a safeguard, it is advisable to add a try-catch block surrounding the TAS calls. This try-catch block should catch all unchecked exceptions, i.e Error and RuntimeException.

4.2. Initialization and Finalization

Before an application can start using TAS, it must make a call to the

TasInitialize() function. This function sets up TAS and activates the protection

after loading the application security manifest. When this function returns with a

successful result, the application can safely assume all configured protections are

active and it is safe to call any other library API.

TasInitialize() must only be called once in the application lifetime, from a

single thread. This is typically done early at the application startup phase to gain

protection as soon as possible.

When done working with the library, the application should call TasFinalize().

This allows TAS to cleanup and prepare for exit from the application. The thread calling

TasFinalize() must be the same one that called TasInitialize().


4.2.1. Initialization Flags

The SDK provides several flags that can be used during initialization. The flags should

be combined together using a bitwise OR and then passed to the TasInitialize()

function.

The following are examples of the flags:

TAS_INIT_NO_OPT --- used to specify that there are no special initialization

options.

TAS_INIT_SUPPRESS_LOGS --- used to suppress sending information to the log.

TAS_INIT_MANUAL_BG_OPS --- used to set whether the TAS operates in manual

or autonomous mode. Refer to the following section for more information.

Other flags can be found in the taslib.h file, which can be found under:

$TAS_ROOT/platform/ios/include

For example:

TAS_INIT_OPTIONS initOptions; initOptions |= TAS_INIT_MANUAL_BG_OPS; TasInitialize(&clinfo, NULL, initOptions);

4.3. Background Operations

TAS may need to perform various background operations during application runtime.

This includes periodic tasks such as receiving updates for the configuration and

recalculating the device risk assessment.

TAS background operations may run in two modes:

Manual Governed - the application periodically signals TAS it can carry out

background operations.

Autonomous - the application lets TAS decide on execution times for

background operations.


The application can query TAS as to whether background operations are executing at

any given moment by calling TasWaitForBackgroundOps(), and passing a zero-

timeout value. In addition, this function may be used to actually wait for TAS

background operations to complete by specifying a non-zero timeout value.

4.3.1. Manual Governed Mode

Manual Governed mode is activated by including the flag in the call to

TasInitialize(). For example:

TAS_INIT_OPTIONS initOptions; initOptions |= TAS_INIT_MANUAL_BG_OPS; TasInitialize(&clinfo, NULL, initOptions);

In Manual Governed mode, it is the application’s responsibility to periodically signal

TAS to initiate performing background operations. This is accomplished using one of

two functions:

TasStartBackgroundOps() --- this function signals both configuration

updates and risk re-assessments. At a minimum it should be called on

application startup.

TasDraRecalcRiskAssessment() --- this function triggers an immediate

recalculation of the risk score.

The application should ideally invoke these calls at times where it detects the user is

idle and/or on application startup. The calls are non-blocking --- background

operations are performed by TAS on a separate thread.

4.3.1.1. Order of Operations

When running with Manual Governed mode, care must be taken to issue the

operations in the correct order. Specifically, the recalculation of the risk items, using

TasDraRecalcRiskAssessment(), must be called before obtaining the

TAS_OBJECT using TasDraGetRiskAssessment(). For example, the following

code shows the correct order or operations:


TAS_OBJECT tasO; TAS_RESULT tasResult = TasDraRecalcRiskAssessment(TAS_DRA_FORCE_RECALC); if (tasResult == TAS_RESULT_SUCCESS) { tasResult = TasDraGetRiskAssessment(&tasO); if (tasResult == TAS_RESULT_SUCCESS) { int count = 0; tasResult = TasDraGetRiskItemCount(tasO, &count); if (tasResult == TAS_RESULT_SUCCESS){

4.3.2. Autonomous Mode

Autonomous mode is the default operating mode for TAS. No configuration is

necessary.

No other action is necessary since checks are performed automatically.

Note that while in Autonomous mode you can manually call

TasDraRecalcRiskAssessment() to initiate an immediate risk score

recalculation if needed for a single action.

4.4. Multithreading Issues

Except when explicitly specified otherwise, all TAS calls can be safely made from any

application thread.

4.5. Error Reporting

All TAS API calls return an error code, of type TAS_RESULT. This is an integer whose

value can either be 0 to indicate success, or nonzero to indicate failure. The header file

taslib.h supplied with the SDK contains definitions of valid error codes.

4.6. Security Manifest

The TAS security manifest contains static configuration information read by TAS on

startup. The manifest is compiled from a set of source files arranged in a specific

directory structure; these source files are typically in JSON format with a specific

schema.


During compilation the security manifest contents are encrypted and signed with a

private key belonging to the application vendor. The encrypted, compiled file should

be bundled with the application:

As a resource named tas/manifest.rpkg

Note: The private key used to compile the manifest file must correspond to a public key which is embedded as part of the vendor’s client key (received in the license file). This ensures that only the vendor is able to compile manifests for use by the application. The vendor client key is described in Step 4: Add Library Initialization and Finalization Calls.

Upon startup TAS reads the manifest and applies its configuration. A template security

manifest is provided as part of the TAS SDK, in the folder

$TAS_ROOT/platform/ios/default_manifest. This template should be

used as the starting point for creating the security manifest.

The manifest compiler can be found in $TAS_ROOT/tools/tmc.jar. The compiler

is invoked from a command prompt using the following java command:

java -jar tmc.jar <manifest_root> <output_filename> <private_key> <keystore_password> <key_password> <key_alias>

The arguments are defined as follows:

manifest_root --- Root of manifest source directory tree, e.g.:

$TAS_ROOT/platform/ios/default_manifest

output_filename --- Output manifest filename.

private_key --- Path of keystore (JKS) containing vendor’s manifest private key.

keystore_password --- Password of keystore containing manifest private key.

key_password --- Password used to protect the vendor’s manifest private key

within the keystore. This is usually the same as the keystore_password.

key_alias --- Alias of the vendor’s manifest private key within the keystore. The

default value is the string mykey.


For example, the following command line will compile the default manifest template

into an output file called manifest.rpkg, using the keystore found at

~/codesign/privatekey.keystore which is protected by password

<MY_KEYSTORE_PASSWORD>.

java -jar tmc.jar ../platform/ios/default_manifest ~/build/manifest.rpkg ~/codesign/privatekey.keystore <MY_KEYSTORE_PASSWORD> <MY_KEY_PASSWORD> mykey

The private key with alias mykey protected by password

<MY_KEYSTORE_PASSWORD> within that keystore will be used for compiling the

manifest.

The compiler validates the input source tree to detect missing or invalid configuration.

The security manifest source tree consists of the following sub-directories and files.

The contents of some of these items are further described in the corresponding

sections of this document.

The manifest provides configuration for the following settings:

1. Minimizing external communications --- refer to section Minimizing External

Communication.

2. Update host server --- refer to section Changing the Configuration Update Host

Server.

3. Proxy --- refer to section Communication Using a Proxy.

4. Device key generation --- refer to section Device Key Creation.

Note: The TAS Manifest Compiler, tmc.jar, requires support for big RSA keys in Java. If your installation of the JRE does not support big RSA keys you will receive an error about an invalid key size. Consider installing the JCE Unlimited Strength Jurisdiction Policy Files into the JRE. Please download the version that is compatible with the version of Java that is installed on your computer: Java Version 6: http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html Java Version 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html


http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html




5. Using Device Risk Assessment

5.1. Obtaining the Risk Assessment Object

A handle to the device risk assessment object is necessary to perform all risk

assessment related operations with TAS. To obtain the risk assessment object, invoke

the TasDraGetRiskAssessment() function which returns the needed handle.

When done with this object, invoke TasDraReleaseRiskAssessment() to

indicate the object is no longer required by your application.

Only one handle to the risk assessment object is available at any time. An attempt to

call TasDraGetRiskAssessment() while a handle is still in use (that is, before a

prior call to TasDraGetRiskAssessment() had been matched with a

TasDraReleaseRiskAssessment() call) will result in a failure of the call, which

will be indicated by an appropriate return value.

It is recommended that you do not keep the handle to the risk assessment object alive

for long periods. This minimizes the risk of someone else obtaining the risk assessment

handle. Also, background risk assessment recalculation is suppressed while the handle

is alive.

An example of this operation is given in section Order of Operations.

5.2. Querying Risk Assessment Factor Results

Once the application obtains a risk assessment object, it can query it for risk

assessment factor results in two ways --- either by enumerating all configured risk

factors, or by querying a specific risk score factor for its values. In both access modes

risk item info is returned in a TAS_DRA_ITEM_INFO structure, that includes

information on the item value, calculation time, and an object handle providing access

to additional data.


To enumerate all risk assessment factors, use TasDraGetRiskItemCount() first

to obtain the count of risk assessment factors, and then call

TasDraGetRiskAssessmentItemByIndex() with varying indices to obtain the

factors, one by one.

To query for a specific risk assessment factor, use

TasDraGetRiskAssessmentItemByName() and specify the name of the risk

factor you wish to query.

An example of this operation is given in section Order of Operations.

Note: All information returned in a TAS_DRAW_ITEM_INFO structure, and specifically the additional data object handle, are only valid as long as the risk assessment object handle is not released.

5.3. Controlling Device Risk Information Calculation

Device risk assessment is automatically calculated as a background task (either by the

TAS background tasks thread or cooperatively when invoked by the application).

However, in some cases the client application may desire to explicitly trigger a device

risk assessment calculation (for example, before displaying current risk assessment to

the user or in response to an explicit user request). To trigger risk assessment

recalculation, use the TasDraRecalcRiskAssessment() function.


5.4. Risk Factor Definitions

The following is a list of the risk factors. The complete list is subject to configuration

downloaded from IBM servers.

Name Description

tas.config_update TAS configuration update status. Indicates the time since the last communication with the update server. Possible values: 0-1000. • 0 means the configuration is up-to-date. • Other values represent the time since the configuration was updated,

where larger values represent more time since an update. os.ver_up_to_date OS version is the most up-to-date, or does not contain known severe

security flaws. Possible values: • 0 means OS version is up-to-date. • Values other than 0 mean that the OS is not up-to-date. The values are defined as follows: • 1000 --- versions prior to iOS 7 • 0 --- version 7 and up

Note: These values will change as new versions are released.

os.rooted OS is jailbroken Possible values: • 0 means the device is not jailbroken. • 1000 means the device is jailbroken.

os.rooted.hiders OS is hiding the fact that it is jailbroken. • 0 means the device is not hiding the fact that it is jailbroken. 1000 means the device is hiding the fact that it is jailbroken.

malware.any Malware detected on device. Additional information field provides summary of detected malware types. Possible values: • 0 means no malware was detected. • 1000 means that malware was detected on the device.


6. Using SSL Certificate Validation

6.1. Configuring the SSL Certificate Validation

The SSL certificate validation mechanism is configured by including a file in the path

ap/ssl_validation_engine.json under the root of the manifest source file system.

The contents of the pharming protection configuration file are as follows.

[ { "@class": "ssl_validation_manager", "@id": "ssl_validation", "providers": [ { "@class": "taz_api_ssl_validation_request_provider", "@id": "taz_request_provider" } ], "protection_policies": [ { "@class": "taz_openssl_ssl_validator", "@id": "taz_ssl_validator", "protected_hosts":["www.trusteer.com"] } ] } ]

The protected_hosts array consists of one or more hosts that should be protected

by the SSL validation system.

The SSL validation requires whitelist and blacklist configuration files with a list of

certificates in PEM format named whitelist.pem and blacklist.pem respectively. A

certificate is valid if it or one of its CAs is in the white list, and neither it nor one of its

CAs is in the black list.

Example:

-----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV XRzIFB0eSBMdGQwHhcNMTExMjMxMDg1OTQ0WhcNMTIxMjMwMDg1OTQ0WjBF A .... MANY LINES LIKE THAT .... .... MANY LINES LIKE THAT .... C3Fayua4DRHyZOLmlvQ6tIChY0ClXXuefbmVSDeUHwc8YufRAERp2GfQnL2JlPUL vA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE-----


NcuvtJogt0s9dXpHowh98FCDjnLtCi8du6LDTZluhlOtTFARPlV/LVnpsbyMCXMs G2qpdjJop+XIBdvoCz2HpGXjUmym8WLqt+coWwJqUSwiEba74JG93v7TU+Xcvc00 .... MANY LINES LIKE THAT .... .... MANY LINES LIKE THAT .... FS5G13pW2ZnAlSdTkSTKkE5wGZ1RYSfyiEKXb+uOKhDN9LnajDzaMPkNDU2NDXDz SqHk9ZiE1boQaMzjNLu+KabTLpmL9uXvFA/i+gdenFHv -----END CERTIFICATE-----

6.2. Validating an SSL Certificate

Validating an SSL certificate is done using TasApharmValidateSslCert(). The

function expects a 0-terminated buffer of DER-encoded certificates in the format

[DER_certificate_representation_1_length, DER_certificate_r

epresentation_1, DER_certificate_representation_2_length, D

ER_certificate_representation_2,...,0]

Note: The length must be written in little endian order.

The following is example code for getting the certificate chain from an

NSURLConnection:

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { CFMutableDataRef certificate_chain = CFDataCreateMutable(nil, 0); // extract the certificates SecTrustRef trustRef = [[challenge protectionSpace] serverTrust]; CFIndex count = SecTrustGetCertificateCount(trustRef); for (CFIndex i = 0; i < count; i++) { SecCertificateRef certRef = SecTrustGetCertificateAtIndex(trustRef, i); CFDataRef cert_data = SecCertificateCopyData(certRef); uint32_t data_len = CFDataGetLength(cert_data); CFDataAppendBytes(certificate_chain, (UInt8*)&data_len, sizeof(data_len)); CFDataAppendBytes(certificate_chain, CFDataGetBytePtr(cert_data), data_len); CFRelease(cert_data); } uint32_t zero = 0; CFDataAppendBytes(certificate_chain, (UInt8*)&zero, sizeof(zero));


7. Using the Device Key

TAS supports providing a device identifier unique to the device. The device identifier

has the following properties:

The identifier consists of 64 hexadecimal digits.

A different identifier is provided for different TAS applications.

The identifier remains constant until the device is completely reset (complete

wipe).

The device key allows lookup of security information about the device using IBM

services such as the Trusteer Management Application (TMA).

To obtain the device key for the current application, use the TasGetDeviceKey()

API.


8. Security Best Practices

This section describes best practices for implementing the Mobile SDK. The best

practices include methods to make it more difficult to reverse engineer or de-compile

your app.

8.1. Application Flow

It is recommended to introduce code obfuscation when calling the SDK API key

functions such as TasDraRecalcRiskAssessment(). You can add branching,

conditionals and iterative constructs that produce valid forward logic, but yield non-

deterministic semantic results when de-compilation is attempted.

8.2. Encryption of Strings in the SDK

All sensitive strings inside the code should be encrypted. These strings may reveal

information about the security logic used by the application.

The Mobile SDK supports the encryption of its own string literals.

To encrypt the strings:

1. In the Xcode build settings change Write Link Map File to YES.

2. Add a Run script build phase after the Link Binary With Libraries phase.

3. From a terminal, call the Ruby script for each architecture:

ruby $TAS_ROOT/platform/ios/build_scripts/encrypt_tas.rb <PATH_TO_BINARY> <PATH_TO_ARCHITECTURE_MAP_FILE>

You may use the supplied bash script instead by calling:

source $TAS_ROOT/platform/ios/build_scripts/encrypt_binary.sh


8.3. Obfuscation and Symbol Stripping:

Strip all symbols from the executable binary using Apple’s strip command. For

example, add a run script at the end of the build scripts section:

if [ $CONFIGURATION = 'Release' ] then strip -x $TARGET_BUILD_DIR/$EXECUTABLE_PATH; fi

You can find a sample script in the SDK in the following directory:

$TAS_ROOT/platform/ios/build_scripts/strip_on_release.sh


9. Malware ID Numbers

The malware.any parameter returns additional information containing the names of

malware that have been detected on the device. The malware name can either be sent

as plain text or as an ID number.

The default delivery method uses the plain text malware names. If you would like to

use the malware ID numbers, please notify your IBM Representative.

An example using the malware ID number is given in Risk Score Output Examples.


10. Testing on an iOS Device

This section describes tests that can be run to test the implementation of the Mobile

SDK.

10.1. Cydia Repository

To ease the testing tasks on jailbroken devices, IBM has a Cydia repository with demo

apps that simulate pharming and malware attacks.

To add the repository:

1. Open Cydia.

2. Select Manage > Sources > Edit > Add.

3. Enter: http://www.trusteer-testing.com/cydia.

4. Add Source > Return to Cydia.

You now have the Cydia repository available on your device.

To install test attack apps:

1. Open Cydia.

2. Select Search.

3. Enter Trusteer in the search box.

4. Choose app to install.

5. Select Install > Confirm > Return to Cydia.

You now have the test attack apps installed on your phone.


10.2. Testing Jailbreak Detection

The following procedure explains how to test that the appropriate alert triggers when

entering a protected website with a jailbroken device.

To test Jailbreak Detection on iOS:

1. Use a jailbroken device.

2. Open your app.

3. Execute the actions necessary to trigger your apps security checks.

4. Check that you receive the appropriate warning message from your app or that

the app execution was prevented (depending on what the app is supposed to

do with the risk score output).

10.3. Testing Malware Detection

To test Malware Detection on iOS:

1. Install the malware iKee.B by installing the app Trusteer Malware Demo from

the Cydia repository. This is a weakened malware which cannot cause damage

to your device.

Refer to Cydia Repository for installation instructions.

2. Open your app.

3. Execute the actions necessary to trigger your apps security checks.

4. Check that you receive the appropriate warning message from your app or that

the app execution was prevented (depending on what the app is supposed to

do with the risk score output).

Note: When you are finished with this test you should remove the test attack app from your device.


11. IBM Security Trusteer Mobile Risk Engine

The Mobile Risk Engine (MRE) provides account takeover detection capability for the

mobile platform. When a user accesses the online banking site, device and session and

risk attributes are remotely collected from the user’s endpoint as well as the associated

account ID. Collected information is used to generate a risk profile for the session

based on multiple parameters such as device ID, device risk data, previously

compromised credentials, geo-location data, and velocity checks. MRE correlates this

data in real-time with other data sources such as real-time malware infection and

phishing incidents, as well as information from endpoint clients and feedback from the

banks, to conclusively identify criminal account access. The data on the IBM servers

does not contain any personally identifiable information (PII).

11.1. System Flow

The MRE has the following flow:

1. Collect device data, including device risk parameters, session ID, PUID, and

device identifier.

2. Encode device data.

3. Send device data to the MRE.

4. Retrieve security recommendation.

The section below details step 1 above. The rest of the steps, including what device

data is collected, are described in the IBM Security Trusteer Mobile Risk Engine

Deployment Guide.

You can also refer to the IBM Security Trusteer Mobile SDK API Reference Guide for more

details on the APIs.


11.2. Device Data Collection

The following flow is used to collect the device data:

1. Create an MRE object using TasAtoCreateSession(). This returns an

object that is linked to the relevant session ID (which is provided by the bank).

2. Set the user ID in the MRE object using TasAtoSetUserId().

a. The user id is hashed and encrypted based on a public key retrieved from

the configuration.

b. Information about the user ID (PUID) can be found in Permanent

User/Account Identifier.

3. (Optional) Set any extra data in the MRE object using

TasAtoSetAuxiliary().

a. The extra data are key/value pairs defined by your organization.

4. (Optional) Extra data can be removed using TasAtoRemoveAuxiliary().

a. Remove extra data associated with a specific key.

5. Get the device data using TasAtoGetCommunicationPayload().

a. This function must be called twice. The first time, call the function with

blob=NULL (the second parameter). This returns the device data size as the

length value.

b. The second call to the function returns the device data, which is already

encrypted.

6. The encrypted device data needs to be encoded and sent to the MRE (as

describe in the IBM Security Trusteer Mobile Risk Engine Deployment Guide.

7. Destroy the MRE object and release the associated memory using

TasAtoDestroySession().

The following pseudo-code shows an example of device data collection:

TAS_OBJECT tasObj = NULL;


// Step 1. TasAtoCreateSession const char *bankSessionId = sessionID TAS_RESULT result = TasAtoCreateSession(&tasObj, bankSessionId); // check result if (result != 0) {error} else {success} // Step 2. TasAtoSetUserId result = TasAtoSetUserId(tasObj, user_id]); // check result if (result != 0) {error} else {success} // Step 3. TasAtoSetAuxiliary result = TasAtoSetAuxiliary(tasObj, key, value) // check result if (result != 0) {error} else {success} // Step 4. TasAtoRemoveAuxiliary result = TasAtoRemoveAuxiliary(tasObj,key); // check result if (result != 0) {error} else {success} // Step 5. TasAtoGetCommunicationPayload // Call #1: size_t length = 0; result = TasAtoGetCommunicationPayload(tasObj, NULL, &length); if (![self function:@"TasAtoGetCommunicationPayload" endedWithResult:result] || length == 0) { // Could not extract device data size break; } // Call #2: NSMutableData *data = [NSMutableData dataWithLength:length]; result = TasAtoGetCommunicationPayload(tasObj, (char *)[data mutableBytes], &length); if (![self function:@"TasAtoGetCommunicationPayload" endedWithResult:res] || length == 0) { // Could not extract device data break; }

11.2.1. Permanent User/Account Identifier

MRE requires a permanent identifier for each user/account in the mobile application

in order to keep account profile and history information, such as devices associated

with the account, malware infections and compromised credential history, and

historical access to the account.


Consequently, a permanent user identifier is required to be sent to IBM with each

backend API call. It is recommended to use a Permanent Non-Personally

Identifiable User ID (PUID). The PUID is a unique user identifier provided by the

customer for each user, which does not disclose the user identity and is fixed and

known to the customer and IBM. Having a fixed identifier for a user is essential in order

to keep user profile information collected by MRE consistent over time.

It is preferred to not use part of the user’s credentials (such as the user ID) as PUID, as

these may be replaced from time to time, e.g. during re-credential of the user. It is

recommended to use a value that will remain constant over time, such as a user’s serial

number in the DB. In case no such value is available, a default PUID should be used

according to the instructions in the section below.

11.2.1.1. Default PUID

In case there is no other user identification available, a one-way hashed form of the

user ID should be used as the default PUID. For this case, IBM provides the one-way

hashing algorithm that the customer can use as part of the data collection process

within the mobile app.

In cases where more than one ID field is used in the PUID (for example in a business

application that requires Company ID and User ID), the string containing all values will

be formatted as follows:

First_Field_Value|Second_Field_Value|Third_Field_Value

A pipe character (‘|’) is used as a separator, without spaces. If all fields are not captured,

empty fields are blank, and the separating pipe is not omitted.

11.2.1.2. PUID for Unidentified User

The PUID cannot be NULL or empty. In a case where the PUID cannot be found (for

example, if the credentials submitted are not correct), the PUID should be formatted

in the following pattern: INV_PUID_<hashed User ID>

Note that this is the same format as for the default PUID defined above, preceded by

the "INV_PUID_" prefix.


12. Advanced Configuration

This section describes various topics for advanced Mobile SDK developers.

12.1. Changing the Configuration Update Host Server

The default host for getting configuration updates is mupdates.trusteer.com. The host

can be overridden using a setting in the manifest.rpkg file.

To change the host, create a JSON file preferences.json in the root folder of the manifest

files or edit the file if it already exists. Add the following code to the file:

{ "configuration_update_host" : { "host" : "www.your-server-name.com/updates" } }

In host key specify the URI allocated for IBM's update requests.

The new host has the following requirements:

SSL --- Do not specify HTTPS in the preferences.json file since update requests are

always sent SSL.

HTTP headers --- All HTTP headers, including extension headers (starting with X-

Trusteer-) sent by the mobile client should be passed without modification.

HTTP methods --- The host should support common HTTP methods. At a

minimum, HEAD, GET, PUT, POST and DELETE must be supported.

Certificates --- the host should use a server certificate signed by a known and

respected CA so that IBM does not need to install CA certificates.

The events host will be configured by IBM, according to the events URI that you

provide, since the events host is determined by our regular configuration.


http://mupdates.trusteer.com/

12.2. Communication Using a Proxy

Some customers may want to route all Mobile SDK communication through a proxy

server. The proxy can be set via the manifest.rpkg file.

To set a proxy server, create a JSON file preferences.json in the root folder of the

manifest files or edit the file if it already exists. Add the following code to the file:

{ "default_proxy" : { "url" : "192.123.123.1", "username" : "user1", "password" : "pass1" } }

The parameters for the default proxy server are defined as follows:

url --- URL of the proxy server. The URL can be specified with a port, e.g.:

"url" : "192.123.123.1:8888",

username --- username for the proxy (optional).

password --- password for the proxy (optional).

12.2.1. Testing Communication with the Proxy Server

Communication with the proxy server can be checked by using software to monitor

the traffic to the proxy server, resulting in the following configuration:

Figure 1: Proxy Testing Architecture


To check the proxy server communication:

1. Download and install traffic monitoring software. A common version of this

type of software is called Fiddler which can be found at:

2. Open the Wi-Fi settings on your mobile test device.

3. Set the proxy in the Wi-Fi settings to the traffic monitor that was setup in step 1.

4. Trigger a configuration update.

a. If you are in Manual Governed Mode, then you need to call

TasStartBackgroundOps.

b. You will see the following lines in the log file:

Background task [configuration-update-task]: Starting Background task [configuration-update-task]: Finished

c. Note that the SDK may take up to several hours in between configuration

updates. Therefore, if your app was running before your traffic monitoring

software was configured, you may not see any traffic for an extended period

of time. To force an update, you can uninstall your app, reinstall it, and then

open the app.

When the configuration update occurs you will see traffic through your proxy server,

confirming that everything is communicating correctly.


13. Phone Gap

PhoneGap (http://phonegap.com/) is a free and open source framework that allows

easy creation of mobile apps using standardized web APIs for different platforms. This

framework can be used to create an app that incorporates the Mobile SDK (starting

with version 3.2). The following sections explain how to create such an app.

13.1. Using PhoneGap with iOS

To create an iOS app that uses the Mobile SDK:

1. Create an iOS PhoneGap project. For instructions, refer to:

http://docs.phonegap.com/en/edge/guide_cli_index.md.html#The%20Com

mand-line%20Interface

2. Link the project with the libtas_phonegap_plugin.a library.

3. Copy tas.js to www/js directory.

4. Add the following line to www/index.html:

<script type="text/javascript" src="js/tas.js"></script>

5. Add the following lines to config.xml:

<feature name="Tas"> <param name="ios-package" value="Tas" /> </feature>

13.2. Mobile SDK API

All Mobile SDK APIs are available for use in the app that was created above, except for

the following APIs:

TasRegisterEventReceiverCallback

TasApharmRegisterPolicyCallback


http://phonegap.com/

http://docs.phonegap.com/en/edge/guide_cli_index.md.html%23the%20command-line%20interface

http://docs.phonegap.com/en/edge/guide_cli_index.md.html%23the%20command-line%20interface

14. Risk Score Output

This section provides examples of the risk score output. The output has the following

parameters:

<status> - text describing the status of the risk score parameter that was

requested.

ItemName --- risk score parameter name.

ItemValue --- numerical value of risk score parameter.

ItemValueTag --- reserved.

LastCalculated --- the last time that the risk parameter was calculated.

AdditionalData --- additional text information about the risk parameter. E.g. the

name of the malware infection.

ItemObject --- reference to the SDK object.

14.1. Risk Score Output Examples

Un-infected device

no malware detected ItemName:"malware.any" ItemValue:0 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "" ItemObject:<REF_TO_OBJECT>

Device with malware infection

1 malware is present: ItemName:"malware.any" ItemValue:1000 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "Citmo;" ItemObject:<REF_TO_OBJECT>


Device with malware infection using malware ID number

1 malware is present: ItemName:"malware.any" ItemValue:1000 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "MAL000042;" ItemObject:<REF_TO_OBJECT>

Device with multiple malware infections

2 malware are present: ItemName:"malware.any" ItemValue:1000 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "Citmo;Kmin-Stealer;" ItemObject:<REF_TO_OBJECT>

Jailbroken device

jailbreak detected ItemName:"os.rooted" ItemValue:1000 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "" ItemObject:<REF_TO_OBJECT>

Non-jailbroken device

no jailbreak detected ItemName:"os.rooted" ItemValue:0 ItemValueTag:0 LastCalculated:01/25/2013 06:15 AM AdditionalData: "" ItemObject:<REF_TO_OBJECT>


15. Device Key Creation

TAS supports several methods to generate the device key. The generation method is

configured using the file preferences.json under the root of the manifest source

filesystem:

{ "device_key_generation" : { "@class": "public_id_agent_key_generator", "@id": "ak_generation" } }

There are two possible values for the device_key_generation.@class:

1. public_id_agent_key_generator - The device key will be created based on

public API only. This is the default behavior.

2. device_fingerprint_generator - The device key will be created based on

numerous parameters retrieved using private API.

Note: Application that uses this key might be rejected by the AppStore. This key is only for private distribution for in-house AppStore.


16. Minimizing External Communication

Some customers may want to minimize the amount of information that is

communicated to the IBM servers. A setting is provided in the TAS to limit

communication between the client and the IBM servers. When this setting is disabled,

the client’s TAS only sends requests to receive updated security configurations from

the IBM servers as well as information about the client’s license.

This feature is configured using the file preferences.json under the root of the manifest

source file system. For example:

{ "cloud_data_sharing" : { "enabled" : "false" } }

When the setting enabled is set to false, communication is limited as mentioned above.

When set to true, the TAS will send information from the client to the servers, such as

the risk score and configuration request headers.


17. IBM Worklight Integration

IBM Worklight provides an open, comprehensive, and advanced mobile application

platform for smartphones and tablets. The Trusteer Mobile SDK can easily be

integrated with IBM Worklight. A WLC file is provided in the Mobile SDK distribution

that can be used for this integration.

Refer to the IBM Security Trusteer Mobile SDK Integration with IBM Worklight guide for

more details.


18. Mobile SDK Checklist

When the customer completes a design using the Mobile SDK, they send the

completed code to IBM. IBM then checks the code using the following checklist to

ensure that the Mobile SDK was implemented correctly.

Num Item IBM Customer Comments 1 Using the TAS Finalize call: Make

sure that the finalization call is used at least when exiting the application.

☐ ☐

2 As a safeguard, it is advisable to add a try-catch block surrounding the TAS calls. This try-catch block should catch all unchecked exceptions, i.e Error and RuntimeException.

☐ ☐

3 Check if the following items in the manifest are configured correctly: • Device ID • Cloud data sharing

☐ ☐

4 If using Manual mode, make sure TasBackGroundOps() is initiated at least once.

☐ ☐


ibm security trusteer mobile sdk: iospublic.dhe.ibm.com/.../pub/certify/ibm...guide_ios.pdf ·...

Documents