Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Dynamically authentic verification for mobile Apps

IP.com Disclosure Number: IPCOM000244425D
Publication Date: 2015-Dec-10
Document File: 5 page(s) / 133K

Publishing Venue

The IP.com Prior Art Database

Abstract

There are security risks in current mobile applications for example the application without authentic verification maybe re-packaged by third party to add advertisements or malicious codes. And simple static algorithm are not complex enough. The disclosure is to resolve the problem by using dynamical algorithm and properties on backend server side to protect backend service and verify client Application authentic: 1) Pick up algorithms/properties randomly/dynamically for each time application authentic verification 2) properties/algorithms include original mobile framework runtime info to ensure the server side challenge data really running inside original Application Client framework. 3) Customer can customise algorithm on server side, ie. by properties, without restarting the server.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 5

Dynamically authentic verification for mobile Apps

The security risk in current mobile apps includes

1) Most mobile App has no authentic verification and the App maybe re-packaged by third part to add ads or malicious codes
2) Simple static algorithm not complex enough, cracker still can reverse engineer it in several months driven by benefits

As a result,the critical impactis that a faked 3rd party app can

1) Access mobile backend service:

Get authenticity algorithm a released mobile file and create a fake App to consume protected Worklight services.

2) Attack mobile backend server:

What's the worse, simulated mobile client to attack backend services. The simulated clients can CRUD user private information which is a disaster to enterprise customer, especially B2C customers.

3) Released 3rd part fake apps highly impact developer's revenue and reputation, like add/replace ADs in original App

4) Released 3rd part fake apps highly impact end user, like leak privacy or even steal bank account/password

2


2.

.. Summary of Invention

Summary of Invention

Summary of Invention:

::

1


1.

.. Background Background

Background:

::

To resolve the above problem, a invention is using dynamical algorithm and properties on backend server side to protect backend service and verify client App authentic.

1) Pick up algorithms/properties randomly/dynamically for each time app authentic verification

2) properties/algorithms include original mobile framework runtime info to ensure the server side challenge data really running inside original App Client framework.

3) Customer can customise algorithm on server side, ie. by properties, without restarting the server.

The advantage are:

1) Each time's app authentic verification has different algorithm, methods and properties, crackers cannot get a full list to decode the server side challenge data

2) Methods on client side are many and complex enough, fully crack each methods is impossible

3) Methods on client side are binding to mobile framework, it cannot be debug or used in 3rd part App

4) Server side has no algorithm/methods implementation, even if the serve side library leaked, crack still has no idea about next time's algorithm

5) Server side methods/properties/values can be provided by several developers, no developer can get a full list to decode the server side challenge data

3


3.

.. Description

Description

Description:

::

1



Page 02 of 5

Components Structure

2



Page 03 of 5

3



Page 04 of 5

Components description

Mobile Library

Mobile Library includes all the static method APIs will be used on Worklight server.

1) Library will check it is running inside Worklight Runtime Framework by calling Worklight native API. This will prevent 3rd-part directly call library.

2) Static method APIs will get some runtime values to calculate the App authenticity token. Also some API will call Worklight runtime API to ensure the methods running inside Worklight Framework.

3) API use mobile signed key to ensure the app not...