WO2017055512A1

WO2017055512A1 - Method to provide provisioning to an application and authenticating the originating address of a sms-mt

Info

Publication number: WO2017055512A1
Application number: PCT/EP2016/073364
Authority: WO
Inventors: Antoine Galland; Frédéric Paillard; Eric Bretagne; Keng Kun CHANG; Chew Peng LEE; Mikel Lim BORDEN; Sin Jin WONG; Hwee Chee Steven MA
Original assignee: Gemalto Sa
Priority date: 2015-09-29
Filing date: 2016-09-29
Publication date: 2017-04-06

Abstract

The present invention concerns the implementation of an authentication of a sender of a SMS-MT received by an application stored in a user device. The purpose of the present invention is to complete a provisioning phase of the application to be able to authenticate the sender of an unsecure SMS-MT. According to the present invention, any SMS-MT is re-routed to an OTA server. The OTA server is configured to transform the received SMS-MT with a predefined Minimum Security Level (MSL) and a security component configured to authenticate the sender. Then the OTA server forwards the transformed SMS-MT to the user device. When received, the Operating System OS verifies if the predefined Minimum Security Level (MSL) and the security component the expected one. If the verification is successful, the SMS-MT is passed by the OS to the application for process.

Description

METHOD TO PROVIDE PROVISIONING TO AN APPLICATION AND AUTHENTICATING THE ORIGINATING ADDRESS OF A SMS-MT

TECHNICAL FIELD

The present invention generally relates to systems and methods for providing provisioning and secure communications for application.

Particularly, the present invention relates to the implementation of a security for the communication from a remote application server to an application in a user device.

The present invention relates to a system and method for authenticating the originating address of an SMS and secure the communication to existing application comprising none security mechanism.

BACKGROUND ART

Mobile phone communication has become part of our daily lives. One of the most widely deployed and used services is the Short Message Service (SMS). Therefore it has to be reliable as well as secure. However, from an attacker perspective SMS is the most interesting feature besides voice calls, since it requires no or very little user interaction to exploit.

Indeed, besides the normal text messaging by mobile phone users, a lot of administrative payloads are sent in the background mostly unnoticed by the user. SMS is nowadays used in various areas. It is widely deployed and a lot of users rely on it in many situations. This includes (but is not a complete list):

• Notifications: E.g. voicemail and Fax messages,

• Over-The-Air (OTA) programming: Provisioning data and phone settings, · Interchange with other protocols: E.g. Email/Fax gateways,

• Electronic payment: Premium-rate SMS services.

FIG.1 discloses the different entities involved in an Over-The-Air (OTA) programming, in the prior art. A remote server application 10, as shown in FIG.1 , sends at step 1 1 a special binary SMS-MT, comprising for example firmware update, to an application 12 stored in the user device. SMS-MT refers to a message being sent to the application. The message is TERMINATED at the mobile/cellphone end.

This SMS-MT advises the application 12 to process the received firmware update. After the update, a special binary SMS-MO is sent at step 13 from the application to the remote server 10 for indicating a status of such update. SMS-MO refers to a message being sent in from a mobile handset. The message is ORIGINATED at the mobile/cellphone end.

However, these SMS-MT messages sent by an operator or a remote server application are not authenticated and are not limited to being sent by the genuine operator or remote server. Since there is no means allowing to authenticate the originating address of the SMS-MT, users have been subject to online services offering the transmission of spoofed messages.

This security weaknesses is used today to target Over-the-Air (OTA) programming of mobile phones by pushing via SMS settings or firmware updates to the mobile phone from untrusted sources.

To solve this drawback security, it is known to authenticate these messages based on security mechanisms using integrity data such as HMAC to protect users from accepting malicious messages from untrusted sources. However the shared secrets in this process are not secure and often rely on the International Mobile Subscriber Identity (IMSI) number. Due to the possibility of online lookups and IMSIs not being completely random this is an insufficient secret. Attacker can for example send malicious provisioning data to users allowing to hijack/eavesdrop internet connections of the mobile phone by reconfiguring proxy settings. On most mobile phones it is not possible for the user to distinguish between a real carrier configuration SMS and a spoofed one. In some cases, received configurations are as well installed automatically.

Moreover, today most of the existing application server does not provide services to concatenate the SMS-MT with the standard 3GPP 23.048 component which resulting in exposure to hacker. Indeed, since the SMS-MT does not contain security mechanism, the hackers can easily manipulate the TP-DA (Transmission Path Destination Address) value of an application by sending massive administrative command.

In the example illustrated in FIG.1 , the hacker changes the TP-DA to a premium number, at step 14, by sending an administrative SMS-MT command to the application. The application 12 in return, at step 15, sends a SMS-MO to a hacker's server 1 6 instead of its own application server 10 causing monetary damage to the user.

Most of applications are designed with a retry mechanism if they do not receive SMS-MT Acknowledgment from the server. Since the SMS-MO was not delivered to the application server 10, the application's server would not respond with SMS-MT Acknowledgement. The application will continuously retry on sending the SMS-MO to the hacker's server. Continuously sending SMS-MO to the premium number will result on monetary costs for user.

There is a need to eliminate the existing problem where hacker can easily spoof of sender addresses by changing an application's TP-DA.

SUMMARY OF THE INVENTION

The following summary of the invention is provided in order to provide a basic understanding of some aspects and features of the invention. This summary is not an extensive overview of the invention and as such it is not intended to particularly identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented below.

The present invention addresses the aforementioned security drawbacks of transactions through SMS. The present invention relates to a system and method for authenticating the originating address of an SMS and secure the communication to existing application with none security mechanism.

This invention concerns the implementation of a security for the communication from a remote application server to an application in a user device.

This object is achieved through a method directed to authenticate a sender of a SMS-MT received by an application stored in a user device. The purpose of the present invention is to complete a provisioning phase of the application to be able to authenticate the sender of an unsecure SMS-MT. According to the present invention, any SMS-MT is re-routed to an OTA server. The OTA server is configured to transform the received SMS-MT with a predefined Minimum Security Level (MSL) and a security component configured to authenticate the sender. Then the OTA server forwards the transformed SMS-MT to the user device. When received, the Operating System OS verifies if the predefined Minimum Security Level (MSL) and the security component are the expected one. If the verification is successful, the SMS-MT is passed by the OS to the application for process.

According to an embodiment, the present invention proposes an Auto

Provisioning Engine (APE) which is configured to eliminate the existing security problem where a hacker can easily manipulate an application TP-DA (Transmission Path Destination Address).

The Auto Provisioning Engine (APE) application is a security based solution which provides provisioning process and secured communication to the application.

The APE implementation as proposed by the present invention provides at least a Minimum Security Level (MSL) for the applications so that an incoming SMS-MT should be associated with some security mechanism in order to reach the application.

The Minimum Security Level (MSL) as defined in the standard 3GPP 23.048 is used to specify the minimum level of security to be applied to Secure Packets sent to any Receiving Application. The Receiving user device can check the Minimum Security Level before processing the security of the Command Packet. If the check fails, the Receiving user device can reject the messages and a Response Packet with the "Insufficient Security Level" Response Status Code can be sent if required.

In an embodiment, the Minimum Security Level (MSL) greater or equals to 02h is applied on the applications. Hence, the incoming SMS-MT can be associated with this Minimum Security Level (MSL) in order to reach the receiving application.

According to an embodiment of the present invention, both APE and application are installed with at least MSL=02h.

Before the application can start communicating with its own server, the APE is set up for a provisioning phase of the application. Provisioning is the process of preparing and equipping the network to allow it provides (new) services to its user. Auto Provisioning Engine (APE) is a solution configured to provide at least a minimum security to all applications preventing their exposure to hacker from sending SMS-MT to alter their contents. Both APE and application are installed with a p red ef i n ed MSL and loaded into a Security Domain (SD) o f t h e u s e r d evi ce which has its own keys management. Hence, an incoming SMS-MT has a Minimum Security Level (MSL) and a component of the specific keyset in the SD in order to reach the application. SMS- MT with no security will be rejected by the card OS.

In an implementation, the application remains in dormant state if the provisioning is not complete. At the first boot-up, the APE performs provisioning by sending SMS-MO to an OTA-Proxy. The SMS-MO contains of necessary information for the OTA-Proxy to derive a keyset and the security component used to authenticate the SMS-MT. The OTA-proxy comprises a database that indicates for each card, the card manufacturer vendor, the card's identification number, the IMSI, the MSISDN, the master key to derive the keyset which is associated to the application.

Once the keyset and the security component are derived by the OTA-Proxy, the OTA-Proxy transform the received SMS-MT Acknowledgement with the derived keyset and the security component. The OTA-proxy adds to the transformed SMS-MT Acknowledgement a keyset reference number. The OTA-proxy sends to the APE the transformed SMS-MT Acknowledgement indicating completion of the provisioning.

The APE comprises a mechanism to verify that all the SMS-MTs come from pre-defined and authorized servers. The originating address of the received SMS-MT is compared with the list of TP-DA in the EFAPE file. The application checks if the originating address matches one of the TP-DA in EFAPE.

The APE comprises another security mechanism to verify if the keyset reference number of the SMS-MT are using the valid keyset. The keyset number of the received SMS-MT is compared with the list of keyset number in the EFAPE file. The application continue the rest of the processing if only the keyset number matches one of the keyset number in the EFAPE.

Once provisioning is complete, the application updates a Status Flag in an Elementary File EFAPE and unregister itself from Status and Location Status event. The Elementary File (EF) is a set of data units or records which share the same file identifier. It cannot be the parent of another file. There are three types of elementary file: transparent (binary, with variable length records), linear fixed (formatted, with all records having the same fixed length), and cyclic (special formatted, with all records having the same fixed length and when the file is full, the newest record automatically replaces the oldest).

The APE is designed to perform provisioning with multiple OTA-Proxy. The number of OTA-Proxy depends on the number of TP-DA listed in the EFAPE. If there is one TP-DA, the APE performs a provisioning process for one OTA-Proxy. If there is five TP-DA listed in the EFAPE, the APE performs a provisioning process for five OTA-Proxy. The provisioning process is considered complete if the APE received a SMS-MT Acknowledgement from all the OTA-Proxy listed in EFAPE. The main purpose for APE is preventing hacker from sending SMS-MT to alter the content in the application.

The APE could be a Java Card application used for auto provisioning for multiple Security Domain (SD) / OTA Proxy (Data Centre). The Auto Provisioning Engine operates in the background on the SIM cards to perform provisioning for a SD.

In an embodiment, the application frequently checks on the associated TP-DA in

EFAPE to see whether the provisioning phase of that particular TP-DA is complete. The completion of provisioning can be knew through the Most Significant Bit (MSB) of the Length byte of the TP-DA to be updated. If the provisioning is not complete, the application check on the next triggering to set up the provisioning process.

When the application identified that the provisioning process has been completed, the application is ready to process SMS-MT. The application can start sending SMS-MO to the remote server application. The remote server application processes the SMS-MO sent by the application. If a SMS-MT Acknowledgement is required by the application, the remote server application generates an unsecure SMS- MT Acknowledgement (no security) and re-routes it to the OTA-Proxy. The OTA-Proxy is configured to transform the received SMS-MT from a predefined Minimum Security Level (MSL) and a security component generated from the derived keyset. Then the OTA-Proxy forwards the transformed SMS-MT Acknowledgement (with security) to the application.

When the SMS-MT Acknowledgement (with security) is received by the card in the user device, the card OS verifies if the predefined Minimum Security Level (MSL) and the security component associated to the SMS-MT Acknowledgement are the expected one. If not, the OS card discard the received SMS-MT Acknowledgement. If the verification is successful, the SMS-MT Acknowledgement is passed by the OS card to the application for process.

Any SMS-MT sent by the remote server application is forwarded to the OTA- Proxy for adding the Minimum Security Level (MSL) and a security component generated from the derived keyset before it is sent to the application. Hence, all incoming SMS-MT are checked through with the keyset and security applied to the application.

The invention presents also the following advantages:

Apply security mechanism with minimum impact towards existing solutions Provide automatic provisioning process for application.

Apply incoming SMS-MT with GSM 03.48 security mechanism

o Preventing hacker from changing application's TP-DA Minimum changes are required on client's solution

o Add checking on EFAPE file on provisioning status on application, o No changes to application server.

Support provisioning for multiple application.

Use the unique keysets in Security Domain (better security for incoming SMS- MT).

To achieve those and other advantages, and in accordance with the purpose of the invention as embodied and broadly described, the invention proposes a method for authenticating an originating address of a SMS-MT sent by a remote server to a user device application, wherein :

the remote server is configured to generates a SMS-MT to be sent to the application, the generated SMT-MT is forwarded to a third party server,

the third party server is configured to transform the received SMT-MT to a secure SMS-MT, this transformation is made from a generated security component and a predefined Minimum Security Level,

the transformed SMS-MT is sent by the third party server to the user device, when received the operating system of the user device verifies if the Minimum Security Level and the security component associated to the secure SMS-MT are the expected one, if the verification is successful, the transformed SMS-MT is transmitted by the operating system to the application for process.

According to an embodiment of the present invention, the application is loaded into a secure domain of a smart card of the user device. An Auto Provisioning Engine application associated to the application is loaded into the security domain, said Auto Provisioning Engine being configured to set up a provisioning phase of the security of said application at the first start-up or reboot of the user device, said application being ready to receive the SMS-MT if only the provisioning phase is completed.

According to an embodiment of the present invention, during the provisioning phase at the first start-up or reboot of the user device, the Auto Provisioning Engine elaborates a SMS-MO comprising provisioning information and a request to set up a provisioning phase to be sent to the third party server,

from the provisioning information and a predefined master key, the third party server derives a keyset value to encrypt a data, a first integrity data is generated by the third party server from the derived keyset value and the data,

the third party server being configured to generates a secure SMS-MT in response to the received SMS-MO from the user device, said secure SMS-MT comprising the data encrypted, the first integrity data, a reference number of the derived keyset and a generated Security Parameter Indicator to indicate the Minimum Security Level of the SMS-MT,

the third party server transmits the generated secure SMS-MT to the user device in response to the SMS-MO. According to an embodiment of the present invention, during the provisioning phase, when the user device receives the secure SMS-MT:

- the smart card Operating System is configured to retrieve a predefined keysets of the application according the keyset reference number in the SMS-MT to decrypt the encrypted data, from the decrypted data and the retrieved keyset the smart card Operating System computes a second integrity data, the second integrity data is compared to the first integrity data to check if the data has been altered,

- the smart card Operating System is configured to check if the Security Parameter Indicator of the SMS-MT matches with a predefined minimum security level of the application,

- if the two verifications are successful, then the smart card Operating System transmits the SMS-MT to the Auto Provisioning Engine for processing.

According to an embodiment of the present invention, during the provisioning phase, when the Auto Provisioning Engine receives the SMS-MT from the smart card Operating System:

- said Auto Provisioning Engine is checking whether an address of the remote server and the keyset number of the SMS-MT matches with an authorized address list and a keyset number stored in a predefined Elementary File,

- if the verifications are successful, the Auto Provisioning Engine updates a Status flag in the Elementary File indicating that the provisioning phase is completed, the application is then put in a ready to receive SMS-MT mode.

According to an embodiment of the present invention, during the provisioning phase, after sending the SMS- MO to the third party server, the Auto Provisioning Engine is set up in waiting mode for the reception of the secure SMS-MT Acknowledgement from the third party server, the Auto Provisioning Engine comprises a retry process which is set up to send a new SMS-MO from the Auto Provisioning Engine to the third party server.

According to an embodiment of the present invention, after the provisioning phase is completed, a SMT-MT received by the third party server is transformed according to the following steps:

the third party server uses the derived keyset value to encrypt the SMS- MT and to compute a third integrity data from the SMS-MT and the derived keyset value, the third party server being configured to apply to the SMS-MT the Security Parameter Indicator indicating the Minimum Security Level of the SMS-MT, - the transformed SMS-MT comprising the encrypted SMS-MT, the third integrity data, the reference number of the derived keyset and the Security Parameter Indicator.

According to an embodiment of the present invention, when the transformed SMS-MT is received by the user device, the verification made by the smart card operating system comprises the following steps: - the smart card Operating System is configured to retrieve the predefined keysets associated to the application according the keyset reference number in the transformed SMS-MT to decrypt the encrypted SMS-MT, from the decrypted SMS-MT and the retrieved keyset the smart card Operating System computes a fourth integrity data, the third integrity data is compared to the fourth integrity data to check if the SMS- MT has been altered,

- the smart card Operating System is configured to check if the Security Parameter Indicator of the SMS-MT match with a predefined minimum security level of the application,

- if the two verifications are successful, then the smart card Operating System transmits the SMS-MT to the application for processing.

According to an embodiment of the present invention, the Operating System discards the received message SMS-MT, when at least one of the verification failed.

According to an embodiment of the present invention, the integrity data is a MAC value.

According to an embodiment of the present invention, when the application is loaded into the user device without an associated Auto Provisioning Engine, the following steps are set up:

the third party server sends to the user device a command to delete the existing application,

the third party server sends to the user device a command to create a new Security Domain,

the third party server sends to the user device a message comprising a new keyset to be loaded into the new Security Domain,

- the third party server sends to the user device a command to load an Auto

Provisioning Engine into the new Security Domain 22b,

the third party server sends to the user device a command to load a new application to into the new Security Domain, said application being associated to the Auto Provisioning Engine and the new keyset, the new application is ready for the provisioning phase.

According to an embodiment of the present invention, the third party server is an Over-The-Air server, said Over-The-Air server being configured to store in its database provisioning data and master key associated to the application.

The present invention also relates to a system for authenticating an originating address of a SMS-MT sent by a remote server to a user device application wherein the remote server is configured to generates a SMS-MT to be sent to the application, the generated SMT-MT is forwarded to a third party server,

the third party server is configured to transform the received SMT-MT to a secure SMS-MT, this transformation is made from a generated security component and a p red ef i n ed Minimum Security Level, the transformed SMS-MT is sent by the third party server to the user device, when received the operating system of the user device verifies if the Minimum Security Level and the security component associated to the secure SMS-MT are the expected one, if the verification is successful, the transformed SMS-MT is transmitted by the operating system to the application for process.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description will be better understood with the drawings, in which:

FIG. 1 illustrates the different entities involved in an Over-the-Air (OTA) programming of mobile phones through SMS, in the prior art.

FIG. 2 illustrates a logic flow diagram in accordance with an exemplary embodiment of the invention during a provisioning phase of applications.

FIG. 3 illustrates a logic flow diagram in accordance with an exemplary embodiment of the invention during a secure communication from a remote server and an application.

FIG. 4 illustrates a logic flow diagram in accordance with an exemplary embodiment of the invention during a secure communication from several remote servers and several applications.

FIG. 5a illustrates a logic flow diagram in accordance with the prior art during an unsecure Over-the-Air (OTA) programming of mobile phones through SMS.

FIG. 5b to FIG. 5f illustrate a logic flow diagram in accordance with an exemplary embodiment of this invention during the phase of adding a Minimum Security Level of the application illustrated in FIG. 5a.

FIG. 6a and FIG. 6b illustrates a comparison between the different entities involved in an Over-the-Air (OTA) programming of mobile phones through SMS according to the prior art and a secure Over-the-Air (OTA) programming of mobile phones through SMS according to the present invention.

FIG. 7 illustrates a logic flow diagram in accordance with an exemplary embodiment of this invention during a provisioning phase and a secure communication from a remote server to the application resulting from the flow described in FIG. 5b to

FIG. 5f.

FIG. 8 illustrates a table illustrating in an embodiment a content of an EFAPE file. DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

The present invention is not specific to any particular hardware or software implementation, and is at a conceptual level above specifics of implementation. It is to be understood that various other embodiments and variations of the invention may be produced without departing from the spirit or scope of the invention. The following is provided to assist in understanding the practical implementation of particular embodiments of the invention.

The same elements have been designated with the same referenced numerals in the different drawings. For clarity, only those elements and steps which are useful to the understanding of the present invention have been shown in the drawings and will be described.

Further, the mechanisms of data communication between the parties and their environment have not been detailed either, the present invention being here again compatible with usual mechanisms.

Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternatives or additional functional relationships or physical connections may be present in a practical system.

Moreover, when an action is said to be performed by a device, it is in fact executed by a microprocessor in this device controlled by instruction codes recorded in a program memory on said device. An action is also ascribed to an application or software. This means that part of the instruction codes making up the application or software are executed by the microprocessor.

Reference throughout the specification to "an embodiment" or "another embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearance of the phrases "in an embodiment" or "in another embodiment" in various places throughout the specification is not necessarily referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

Specific details are provided in the following description to provide a thorough understanding of example embodiments. However, it will be understood by one of ordinary skill in the art that example embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure the example embodiments in unnecessary detail. In other instances, well- known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring example embodiments.

Also, it is noted that example embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

FIG. 2 shows entities involved in a flow diagram for provisioning a Minimum Security Level (MSL) for the applications. For simplicity of discussion, only one of each entity is shown at FIG.2. FIG. 2 depicts an example of the system in which a mobile device and a server are implemented.

Embodiments of the present invention is exemplified using a mobile communication device (not shown) such as a mobile phone. However, it should be appreciated that the invention is as such equally applicable to electronic devices which have wired- and/or wireless radio communication capabilities. Examples of such devices may for instance be any type of mobile phone, laptops (such as standard, ultra- portables, netbooks, micro laptops, and pads), handheld computers, PDAs, gaming devices, accessories to mobile phones, etc. However, for the sake of clarity and simplicity, the embodiments outlined in this specification are exemplified with and related to mobile phones only.

The mobile phone typically comprises a processor, a memory, input devices, output devices, and suitable communications scheme, all of which are operatively coupled to the processor. The mobile phone comprises a smart card 20. The main authority for this smart card 20 is the Card Issuer, which has full control over the card contents, but he can grant also other Application Providers to administrate their own applications. The Issuer Security Domain (ISD) 21 , as the mandatory on-card representative of the Card Issuer, has the capability of loading, installing, and deleting applications 23 that belong either to the Card Issuer or to other Application Providers.

The ISD 21 comprises a Security Domain (SD) 22. The Security Domain 22 is a protected area on the smart card 20. To this Security Domain 22 are assigned applications 23, which can use cryptographic services it offers. Just as the Issuer Security Domain 21 is the on-card representative of the Card Issuer, the Security Domain 22 is the on-card representative of an Application Provider. The Security Domain 22 supports security services such as key handling, encryption, decryption, digital signature generation and verification for the applications owners (Card Issuer, Application Provider).

By default only the Security Domain 22 of the Card Issuer exists on a given smart card. If another Application Provider wants to have its own Security Domain 22, e.g. for having its own secure application environment or managing its own applications, such a secure domain can be created with the help of the Card Issuer.

All Card have one mandatory Security Domain: the Issuer Security Domain 21 (ISD). A card that supports multiple Security Domains 22 can allow an Application Provider, through its own Security Domain, to manage its own Applications and provide cryptographic services using keys that are completely separate from, and not under the control of the Card Issuer. In an embodiment of the present invention, the Security Domain 22 comprises an Auto Provisioning Engine (APE) application 24. The Auto Provisioning Engine (APE) are utilizing the Security Domain's cryptographic keys which can be used to support Secure Channel Protocol operations and/or to authorize card content management functions.

Security Domains are responsible for their own key management. This ensures that applications 23 and data from different Application Provider may coexist on the same card without violating the privacy and integrity of each Application Provider.

Each application 23 and each Executable Load File is associated with a Security Domain. An application 23 can use the cryptographic services of its associated Security Domain 22. It is possible to associate applications owned by one Application Provider with the Security Domain 22 of another Application Provider.

The Auto Provisioning Engine 24 relies on the Security Domain's keyset to provide secured communication for the application 23.

The Auto Provisioning Engine 24 is not handling the administrative command from an OTA-Proxy 22. The administrative command can be a service that passes through the mobile network operator's radio network. For example, it can be an application personalization commands, or application downloads.

In an embodiment of the present invention, the administrative command from the OTA-Proxy 26 is handled by an Operating System (OS) (not shown) of the smart card 20. The OTA-Proxy sends administrative write command via Remote File Management (RFM) to the smart card 20 to alter/change the content of the Elementary File EFAPE.

When the provisioning process has been completed and the Remote File Management (RFM) to update EFAPE is sent, the Auto Provisioning Engine is retriggered on the next reboot.

FIG.2 illustrates an exemplary flow diagram during a provisioning phase 30 of the application 23. Therein, the process flow between the application 23, the OTA proxy 26 and the remote application server 28 is depicted with labeled arrows to which respective numbers are assigned. The flow is understood as being performed sequentially as indicated by the increasing numbers. However, it should be noted that there may be multiple instances of this protocol run in parallel without specified ordering.

FIG. 2 is a flow chart depicting a set of functions 30 that can be carried out in accordance with an example embodiment. The set of functions 30 can be performed during a provisioning phase of the application. The set of functions 30 are shown within steps 31 through 34. A description of these steps now follows.

At a step 31 , a master key of the application 23, with provisioning information are loaded into the OTA-Proxy 26.

Upon the mobile phone 20 first start-up or is reboot, at step 32, the APE 24 elaborates a SMS-MO comprising provisioning information. The provisioning information can be the contents in EFAPE which can comprise Counter, Protocol Version, User Trigram, UICC Manufacturer, Key Derivation Profile, MVNO/MVNI Indicator, Card Profile ID, ICCID and IMSI.

The SMS-MO are elaborated with no security. This SMS-MO comprising a provisioning request is sent to the OTA Proxy 26 (Data Centre).

The OTA-Proxy 26 checks the received provisioning information and extracts the associated master key. After processing the received the SMS-MO from the APE 24, the OTA Proxy 26 elaborates a SMS-MT Acknowledgement with the security to be applied. For that, the OTA-Proxy 26 uses the provisioning information and the associated master key to derive a keyset value (KIC and KID value). The OTA-Proxy 26 elaborates data to be secured and encrypts it with the derived keyset value. The OTA Proxy 26 generates an integrity data from the data and the derived keyset value. In a non-limitative embodiment, the integrity data is a MAC value. The MAC value can be the result of a MAC (Message Authentication Code) operation on at least one part over the secure data. The MAC operation can use the keyset and a cryptographic integrity data algorithm to produce the MAC value which later can be used to ensure that the data has not been modified.

The OTA Proxy 26 applies necessary Security Parameter Indicator (SPI) on the SMS-MT Acknowledgement elaborated to define its Minimum Security level. The elaborated SMS-MT Acknowledgement comprises also the KIC and KID reference number.

The derivation algorithm and the application of the Security Parameter Indicator (SPI) on the SMS-MT used herein is well known by the person in the art and from the standard and do not need to be described any more.

The OTA-Proxy 26 can store the derived keyset into the OTA-Proxy server 27 at step 33.

The OTA Proxy 26 sends the SMS-MT Acknowledgement to the APE 24. When the SMS-MT is received by the smart card 20, the card Operating System (OS), verifies first the Keysets and second the Minimum Security Level (MSL) of the SMS-MT. The OS Card extracts from the SMS-MT the KIC and KID reference number to identify which keyset in the SD 22 to be used to decrypt the encrypted data. The OS card computes an integrity data from the decrypted data and compares it with the integrity data value in the received SMS-MT to check if the data has been altered.

If the two integrity data matches it means that the keyset derived by the OTA- proxy matches with the keyset in the Security Domain (SD) 22. The OS card checks if the first byte of the Security Parameter Indicator (SPI) of the SMS-MT fulfils the security comparison with the minimum security level MSL of the application 23. If the two verification are successful, then the OS transmits the SMS-MT to the APE 24 for processing. Otherwise, if one of the verification failed, the OS discards the received message SMS-MT. The APE application 24 is using the OS security mechanism in filtering the received SMS-MT. If the security of the SMS-MT does not fulfill, the SMS-MT is rejected by the card OS itself.

Once the APE 24 receives the SMS-MT, the APE 24 performs another checking to ensure that the SMS-MT are coming from the valid OTA-proxy address and the valid keyset number is applied on the SMS-MT. The APE 24 processes the SMS-MT Acknowledgement by checking whether the TP-OA and keyset number of the SMS-MT matches with the TP-DA and Keyset in the EFAPE. If it match, then APE updates the Status Bit of TP-DA Length in EFAPE from for example 0 to 1 to indicate that this particular OTA-Proxy has completed its provisioning phase. The APE 24 updates the Status Bit (The most significant bit - AP status flag bit) of the Length of TP-DA if all the security checking are passed. TP-OA refers to Transmission Path Originating Address. The TP-OA is the SMS header field that contains the message sender's number. TP- DA refers to Transmission Path Destination Address.

Therefore, the completion of provisioning an OTA-Proxy can be known through the Status Bit of the Length of TP-DA.

Otherwise, if one of the verification failed, the APE will stop the process of the SMS-MT.

The Auto Provisioning Engine APE 24 requires the EFAPE files to function properly according to the activated features. The EFAPE file in SIM card is located under MF (3F00) and defined as a linear-fixed file. The File ID of EFAPE could be 0x3737. Example: the complete file path of EFAPE is 3F00/3737. The application 23 does not start provisioning if the file is not present.

The application 23 ca n read and update the content of this EF containing status, keysets, TP-DA, counter, protocol version, user trigram, UICC manufacturer, key derivation profile, MVNO/MVNI indicator and card profile. A structure example of an EFAPE is illustrated in FIG. 8.

In an embodiment, the application 23 sends numbers of SMS-MO depending on number of TP-DA listed in the EFAPE. For example, if the EFAPE comprises two TP-DAs, the application will send SMS-MO to two different OTA-Proxy with different address (TP- DA).

When the application 23 receives the SMS-MT from the OTA-Proxy 26, the application 23 checks on the TP-OA of the SMS-MT against with the TP-DA in the EFAPE to ensure that the SMS-MT is coming from the valid server before updating the TP-DA in EFAPE as complete with provisioning. Apart from that, the application is also checking the keyset KIC and KID reference number of the SMS-MT to ensure that the right keyset reference number is used.

Once the TP-DA is complete with provisioning, the application 23 that is associated with that particular TP-DA is ready to be used. If there is more than one applications in the security domain 22, each of the application can use different keyset number. (Preventing for example counter issue if MSL=16).

After sending the SMS- MO to the OTA-Proxy 26, the Auto Provisioning Engine (APE) 24 is set up in wait mode for the reception of the SMS-MT Acknowledgement. The APE 24 sets up a retry process mechanism, if no SMS-MT Acknowledgement is received. The retry process mechanism is configured to send SMS-MO to the OTA- Proxy 24.

The Auto Provisioning Engine 24 can comprise three different types of retry mechanisms: Auto Provisioning Reboot Counter

Retry if there is SMS-MO Error

Retry if there is no SMS-MT Acknowledgement Received.

Auto Provisioning Reboot Counter

In an embodiment, the Auto Provisioning Reboot Counter can be used to restrict the maximum number of the application attempt of sending SMS-MO to the OTA-Proxy after every reboot. The Auto Provisioning Reboot Counter can be updated via RFM to re-trigger the Auto Provisioning Engine to re-send SMS-MO to the OTA- Proxy. The application can attempt to send SMS-MO to OTA-Proxy at each reboot until a maximum number of attempt has been reached. When the maximum number has been reached, the application can unregister from Status and Location Status event.

Retry if there is SMS-MO Error

In another embodiment, the Auto Provisioning Engine can implement a retry mechanism to re-send the SMS-MO to the OTA- Proxy if the application encounter temporary error when sending the SMS-MO to the OTA-Proxy. The application can retry to send the same SMS-MO for a certain number of times until a maximum number of retry (Retry if there is SMS-MO Error) has been reached. When the maximum number of retries has been reached, the application can attempt of sending the next SMS-MO (if there is more than one TP-DA in EFAPE) or activate "Retry if there is no SMS-MT Acknowledgement (if there is only one TP-DA in EFAPE)".

Retry if there is no SMS-MT Acknowledgement

In another embodiment, the Auto Provisioning Engine can implement a retry mechanism to resend the SMS-MO to the OTA-proxy if the application does not receive the SMS-MT Acknowledgement after N statuses. The application can retry to send the list of SMS-MO for certain number of times until a maximum number of retry (Retry if there is no SMS-MT Acknowledgement) has been reached. When the maximum number has been reached, the application can unregister from Status and Location Status event. The application will be functional on the next boot up or receiving the SMS-MT Acknowledgement from the OTA-Proxy.

FIG. 3 illustrates an exemplary of secure communication flow diagram 40 from the remote server 28 to the application 23. The application 23 remains in idle mode until the provisioning is complete. The application 23 checks on the Status Bit of the Length of the specific TP-DA in EFAPE if the provisioning phase has been completed. Once the Status Bit has been updated meaning that the provisioning has been completed, the application 23 is ready to receive and process SMS-MT from remote server.

At step 41 , the application 23 in ready to use mode can send a SMS-MO to the remote server 28.

The remote server application 28 can elaborate a SMS-MT in response to the received SMS-MO. The remote server 28 will re-route, at step 42, to the OTA-proxy 26 any SMS-MT to send to the application 23. Then the OTA Proxy 26 transforms the received SMS-MT and forwards it to the application 23.

At step 42, the application server SMS-MT for the application 23 is diverted to the OTA-Proxy 26 before sending it to the application 23.

At step 43, Since the OTA-Proxy 26 has derived a keyset during APE performing provisioning, the OTA-Proxy 26 transforms the received SMS-MT with the derived keyset and the MSL before forwarding it to the application 23.

In an embodiment during the transformation of the SMS-MT, the OTA-Proxy 26 encrypts the SMS-MT with the derived keyset value. The OTA Proxy 26 can generate an integrity data from the SMS-MT and the derived keyset value. The OTA Proxy 26 applies necessary Security Parameter Indicator (SPI) on the SMS-MT to define its Minimum Security level. The OTA-Proxy 26 can add to the SMS-MT the keyset reference number. The transformed SMS-MT comprises at least the encrypted SMS- MT, the computed integrity data, Security Parameter Indicator and the keyset reference number.

Then the OTA Proxy 26 sends the transformed SMS-MT to the mobile phone through the SMSC (Short Message Service Center). When the transformed SMS-MT is received by the smart card 20, the card Operating System (OS), verifies first the Keysets and second the Minimum Security Level (MSL) of the SMS-MT. The OS Card extracts from the transformed SMS-MT the KIC and KID reference number to identify which keyset in the SD 22 to be used to decrypt the SMS-MT. The OS card computes an integrity data from the decrypted SMS-MT and compares it with the integrity data value in the received transformed SMS-MT. If the two integrity data matches it means that the keyset derived by the OTA-proxy 26 matches with the keyset in the Security Domain (SD) 22.

The OS card checks if the first byte of the Security Parameter Indicator (SPI) of the transformed SMS-MT fulfils the security comparison with the minimum security level MSL of the application 23. If the two verification are successful, then the OS transmits the SMS-MT to the APE 24 for processing. Otherwise, if one of the verification failed, the OS discards the received message SMS-MT.

The OS transmits the decrypted SMS-MT to the application 23 if the verification security mechanism added to the SMS-MT is successful. If the remote application server 28 attempts to send SMS-MT (with no security mechanism included) to the application, the OS will reject the SMS-MT because the Keyset and the MSL does not match. The present invention allows to prevent hacker from injecting Administrative Command to alter the TP-DA in the application 23.

The proposed solution is designed to be installed with multiple instances. Each instance is responsible of provisioning multiple application 23 in a Security Domain 22.

The Auto Provisioning Engine (APE) can be installed with one instance under the Issuer Security Domain (ISD). The card's operating system is responsible in checking all the incoming SMS-MT with the keyset in the ISD. To allow the APE to provide provisioning to the application 23, the application 23 can be installed in the same directory than the APE (ISD).

As shown in FIG. 4, APE can support installation of multiple instances on a card with a single package. Each instance are meant to be loaded into a dedicated Security Domain (SD) and installed with a record number (Based on the last nibble of the TAR) to associate with one record in EFAPE for provisioning. Each instance may associate with one or more OTA-Proxy depending on the number of TP-DA listed in the respective EFAPE record.

The application can check on the TP-DA in the EFAPE the provisioning status. In an embodiment, the APE instance responsible in provisioning the specific TP-DA for a given application can be loaded in the same SD with that given application.

As illustrated in Figure 4, there are 3 instances of APE 24a, 24b and 24c loaded respectively in 3 different Security Domain 22a, 22b and 22b. Each instance of APE is handling the provisioning phase of one or multiple applications 23 in one Security Domain. Once the provisioning as described in FIG. 2 is completed and the associated TP-DA for a given application 23 is updated, the application 23 can start secured communicating with its own server 28.

FIG. 5a illustrates an application 23 installed with MSL 0x00 in card 20 and already deployed in the field. This application 23 is configured to receive SMS-MT from a server 28 without security.

FIG. 5b to FIG. 5f illustrate an exemplary flow diagram during a provisioning phase for the application 23 installed with MSL 0x00 in card 20 and already deployed in the field as shown in FIG. 5a. Therein, the process flow between the application 23, an OTA manager 29 and the application server 28 is depicted with labeled arrows to which respective numbers are assigned. The flow is understood as being performed sequentially as indicated by the increasing numbers. However, it should be noted that there may be multiple instances of this protocol run in parallel without specified ordering. FIG. 5b to FIG. 5f is a flow chart depicting a set of functions 50 that can be carried out in accordance with an example embodiment. The set of functions 50 are shown within steps 51 through 55. A description of these steps now follows.

At step 51 , an Over-The-Air (OTA) manager 29 is used to update or changes data in smart cards 20 (SIM card or UICC) without having to reissue the cards in the fields. OTA enables a network operator to upgrade the security level of application 23 in a rapid and cost-effective way.

At step 51 , the OTA manager 29 transforms received service requests from network into Short Messages to be sent to the smart card 20. The OTA manager 20 comprises a card database that indicates for each card, the card manufacturer vendor, the card's identification number, the IMSI and the MSISDN. The OTA manager 29 comprises a set of libraries that contain the formats to use for each brand of smart cards.

At step 51 , the OTA manager 29 sends to the smart card 20 a formatted message through the SMSC using the right set of parameters as described in the standards GSM 03.48 or TS 23.048. In this step the OTA manager 29 is responsible for the integrity and security of the process. The formatted message in step 51 comprises a command to delete the existing application 23.

When received, the smart card 20 according to the standard verifies the integrity and the security. If the verification result is successful, the smart card 20 deletes the application 23, as illustrated in FIG. 5b.

At step 52, the OTA manager 29 sends to the smart card 20 a formatted message comprising a command to create a new Security Domain 22b. When received, the smart card 20 according to the standard verifies the integrity and the security. If the verification result is successful, the smart card 20 create the new Security Domain 22b, as illustrated in FIG. 5c.

At step 53, the OTA manager 29 derives the keyset to be associated with the new Security Domain 22b. The OTA manager 29 sends to the smart card 20 a formatted message comprising the new keyset to be loaded into the new Security Domain 22b. When received, the smart card 20 according to the standard verifies the integrity and the security. If the verification result is successful, the smart card 20 puts the received keyset into the new Security Domain 22b, as illustrated in FIG. 5d.

At step 54, the OTA manager 29 sends a formatted message comprising the APE with a predefined Minimum Security of Level to be loaded into the smart card through the SMSC. When received, the smart card 20 according to the standard verifies the integrity and the security. If the verification result is successful, the smart card 20 installs the received APE into the new Security Domain 22b, as illustrated in FIG. 5e.

At step 55, the OTA manager 29 sends a formatted message comprising the application 23 with a predefined Minimum Security of Level to be loaded to the smart card through the SMSC. When received, the smart card 20 according to the standard verifies the integrity and the security. If the verification result is successful, the smart card 20 installs the received application 23 into the new Security Domain 22b, as illustrated in FIG. 5f.

FIG. 6a illustrates a prior art communication flow between the application 23 in a smart card and the remote server.

FIG. 6b illustrates the result of the deletion and the software components installed into the smart card 20 as described in FIG. 5b to FIG. 5f. The software components installed into the smart card 20 are configured to execute the provisioning flow as described in FIG. 2 and to establish a secure communication from the remote server 28 to the application 23 as described in FIG. 3.

In step 56 as illustrated in FIG. 7, the Auto provisioning phase described in FIG.

2 is triggered on the card 20 illustrated in FIG. 6b once the mobile phone reboot. When the Auto provisioning phase is complete, the newly installed application 23 is now ready to receive and process SMS-MT.

At step 57 of FIG. 7, when the application 23 identifies that the provisioning phase is complete, the application 23 can send SMS-MO to the remote server application 28. The remote server application 28 processes the received SMS-MO. In response, the remote server application 28 can elaborate a SMS-MT Acknowledgement to be sent to the application 23. After elaborated, the remote server application 28 re-routes, at step 58, the SMS-MT Acknowledgement (with no security) to the OTA-Proxy 26. The OTA- Proxy 26, at step 59, adds the security mechanism described in FIG.3 to the SMS-MT Acknowledgement. Then the OTA-Proxy 26 forwards the SMS-MT Acknowledgement (with security) to the application 23 for verification and processing as described in FIG. 3.

The terms and expressions employed herein are used as terms and expressions of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described or portions thereof. In addition, having described certain implementations in the present disclosure, it will be apparent to those of ordinary skill in the art that other implementations incorporating the concepts disclosed herein can be used without departing from the spirit and scope of the invention.

For example the OTA-proxy, the OTA-server and the OTA manager can be the same entity or separate entities.

The features and functions of the various implementations can be arranged in various combinations and permutations, and all are considered to be within the scope of the disclosed invention. Accordingly, the described implementations are to be considered in all respects as illustrative and not restrictive. The configurations, materials, and dimensions described herein are also intended as illustrative and in no way limiting. Similarly, although physical explanations have been provided for explanatory purposes, there is no intent to be bound by any particular theory or mechanism, or to limit the claims in accordance therewith.

Claims

1 . Method for authenticating an originating address of a SMS-MT sent by a remote server to a user device application, wherein :

- the remote server is configured to generates a SMS-MT to be sent to the application, the generated SMT-MT is forwarded to a third party server,

the third party server is configured to transform the received SMT-MT to a secure SMS-MT, this transformation is made from a generated security component and a p red ef i n ed Minimum Security Level,

- the transformed SMS-MT is sent by the third party server to the user device, when received the operating system of the user device verifies if the Minimum Security Level and the security component associated to the secure SMS-MT are the expected one, if the verification is successful, the transformed SMS-MT is transmitted by the operating system to the application for process.

2. Method for authenticating an originating address of a SMS-MT, according to the previous claim, wherein the application is loaded into a secure domain of a smart card of the user device, an Auto Provisioning Engine associated to the application is loaded into the security domain, said Auto Provisioning Engine being configured to set up a provisioning phase of the security of said application at the first start-up or reboot of the user device, said application being ready to receive the SMS-MT if only the provisioning phase is completed.

3. Method for authenticating an originating address of a SMS-MT, according to the previous claim, wherein during the provisioning phase at the first start-up or reboot of the user device the Auto Provisioning Engine elaborates a SMS-MO comprising provisioning information and a request to set up a provisioning phase to be sent to the third party server,

the third party server transmits the generated secure SMS-MT to the user device in response to the SMS-MO.

4. Method for authenticating an originating address of a SMS-MT, according to any of the claims 2 to 3, wherein during the provisioning phase, when the user device receives the secure SMS-MT:

5. Method for authenticating an originating address of a SMS-MT, according to any of the claims 3 to 4, wherein during the provisioning phase, when the Auto

Provisioning Engine receives the SMS-MT from the smart card Operating System:

- said Auto Provisioning Engine is checking whether an address of the remote server and the keyset number of the SMS-MT matches with a predefined authorized address list and a keyset number stored in a predefined Elementary File,

- if the verifications are successful, the Auto Provisioning Engine updates a

Status flag in the Elementary File indicating that the provisioning phase is completed, the application is then put in a ready mode to receive SMS-MT.

6. Method for authenticating an originating address of a SMS-MT, according to any of the previous claims, wherein during the provisioning phase, after sending the

SMS-MO to the third party server, the Auto Provisioning Engine is set up in waiting mode for the reception of the secure SMS-MT Acknowledgement from the third party server, the Auto Provisioning Engine comprises a retry process which is set up to send a new SMS-MO from the Auto Provisioning Engine to the third party server.

7. Method for authenticating an originating address of a SMS-MT, according to any of the claims 3 to 6, wherein after the provisioning phase is completed, a SMT- MT received by the third party server is transformed according to the following steps:

the third party server uses the derived keyset value to encrypt the SMS- MT, to compute a third integrity data from the SMS-MT and the derived keyset value, the third party server being configured to apply to the SMS-MT the Security Parameter Indicator indicating the Minimum Security Level of the SMS-MT, the transformed SMS-MT comprising the encrypted SMS-MT, the third integrity data, the reference number of the derived keyset and the Security Parameter Indicator.

8. Method for authenticating an originating address of a SMS-MT, according to the previous claim, wherein when the transformed SMS-MT is received by the user device, the verification made by the smart card operating system comprises the following steps:

- the smart card Operating System is configured to retrieve the predefined keysets associated to the application according the keyset reference number in the transformed SMS-MT to decrypt the encrypted SMS-MT, from the decrypted SMS-MT and the retrieved keyset the smart card Operating System computes a fourth integrity data, the third integrity data is compared to the fourth integrity data to check if the SMS- MT has been altered,

9. Method for authenticating an originating address of a SMS-MT, according to any of the previous claims, wherein the Operating System discards the received message SMS-MT, when at least one of the verification failed.

10. Method for authenticating an originating address of a SMS-MT, according to any of the claims 3 to 9, wherein the integrity data is a MAC value.

1 1 . Method for authenticating an originating address of a SMS-MT, according to any of the previous claims, wherein when the application is loaded into the user device without an associated Auto Provisioning Engine, the following steps are set up:

- the third party server sends to the user device a command to create a new

Security Domain,

the third party server sends to the user device a command to load an Auto Provisioning Engine into the new Security Domain 22b,

the third party server sends to the user device a command to load a new application to into the new Security Domain, said application being associated to the Auto Provisioning Engine,

the new application is ready for the provisioning phase.

12. Method for authenticating an originating address of a SMS-MT, according to any of the previous claims, wherein the third party server is an Over-The-Air server, said Over-The-Air server being configured to store in its database provisioning data and master key associated to the application.

13. System for authenticating an originating address of a SMS-MT sent by a remote server to a user device application through a third party server according to any of the previous claims.