Abstract:
A system includes at least one telecommunications terminal having data processing capabilities, the telecommunications terminal being susceptible of having installed thereon software applications, wherein each software application has associated therewith a respective indicator adapted to indicate a level of security of the software application, the level of security being susceptible of varying in time; a software agent executed by the at least one telecommunications terminal, the software agent being adapted to conditionally allow the installation of software applications on the telecommunications terminal based on the respective level of security; a server in communications relationship with the software agent, the server being adapted to dynamically calculate the level of security of the software applications, and to communicate to the software agent the calculated level of security of the software applications to be installed on the telecommunications terminal.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    The present invention generally relates to the field of security enforcement on telecommunications terminals, either mobile or wired, and particularly to the enforcement of security of the application layer in telecommunications terminals having an open operating system, that allows the installation (and execution) of third-party software applications. 
         [0003]    2. Description of Related Art 
         [0004]    The diffusion and evolution of mobile telecommunications terminals (e.g., mobile phones of the last generation), in terms of computational power of the terminal, available communication bandwidth, availability of services and of software applications specifically designed for the telecommunications terminals, is widening the breadth of the services that the telecommunications terminals can make available to the users, and the modalities of accessing the telecommunications networks. 
         [0005]    Nowadays, the availability of communication bandwidth and of computational power on mobile telecommunications terminals with an open operating system like Windows Mobile, Symbian, or SavaJe, has made it possible to offer new added-value services, and the adoption of “always on” connectivity profiles (i.e., the user of the telecommunications terminal is always connected to a telecommunications/data communications network, and can at any time access the offered services). Examples of these new services are the unified messaging (e-mail, instant messaging, Short Messaging Service—SMS—, Multimedia Messaging Service—MMS), secure access to enterprise&#39;s resources over IP (Internet Protocol) channels by the employees (for example by means of protected tunnels with protocols like TLS/SSL—Transport Security Layer/Secure Socket Layer—, IPsec—IP security—, L2TP—Layer 2 Tunnel Protocol—and the like), services of Digital Rights Management (DRM), access and exploitation of multimedia contents (based for example on the DVB-H—Digital Video Broadcasting-Handheld standard), access to enterprise&#39;s services and applications, and so on. 
         [0006]    The availability of these powerful mobile telecommunications terminals is a great market opportunity, also considering the broad target of customers that can be reached by customized offers. However, such powerful terminals bring about security issues also in connection with the core business of the mobile telecommunications network operator. The mobile terminal is, under several respects, particularly vulnerable to software attacks: just to cite some examples, the mobile terminal is usually devoted to a personal use, it stores sensitive information (both of personal and of professional nature), it has a money credit associated with the SIM (Subscriber Identity Module), it stores information (like the IMSI—International Mobile Subscriber Identity—and the IMEI—International Mobile Equipment Identity) that allows an easy tracking of the user, it has access to wide communication bandwidth (e.g., GPRS/EDGE/UMTS), and it may implement different types of connectivity (like for example Wi-Fi, Bluetooth, IrDA—Infrared Device Application—, NFC—Near Field Communication, ZigBee). 
         [0007]    Today, the security issues that involve mobile telecommunications terminals are mainly due to the sensitivity of the user (Social Engineering), and the diffusion of Trojan-type malware. A user of a mobile phone usually is less sensitive to security issues compared, for example, to a user of a Personal Computer (PC); this is in part due to the higher diffusion of mobile phones compared to PCs, and to the fact that a phone is generally perceived as a secure device, so users are not accustomed to consider that their mobile phones may be subject to software attacks. 
         [0008]    Nowadays, the circulating malware is essentially of the Trojan type; thus, it rarely exploits the vulnerability of the software resident on the mobile terminal, rather it uses a “cover” application for installing on the terminal, after having obtained the user&#39;s authorization (and in this respect the low sensitivity of the user plays an important role), and then perpetrating the attacks for which it is designed (for example sending SMS to premium numbers, deleting user files and documents, illegally forwarding e-mail and other types of messages, replicating itself). 
         [0009]    Several initiatives have been promoted for finding solutions to the increasing demand for higher security, driven in part by the diffusion of several malware applications. Some of the most important initiatives are the Microsoft Mobile-2-Market (http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/default.aspx), Symbian Signed (http://www.symbiansigned.com), OMTP (Open Mobile Terminal Platform) P6 Application Security Project (hftp://www.omtp.org), GSM-A MAS (Mobile Application Security) Project (http://www.gsmworld.com/using/security/mobile_application.shtml), Java MIDP (Mobile Information Device Profile) 2.0 (http://java.sun.com/products/midp/index.jsp). 
         [0010]    In general, all the known initiatives are based on a same model, hereinafter referred to as the “trust model”, which generally defines two macro-categories of software applications that can run on a mobile telecommunications terminal: trusted applications and non-trusted applications. 
         [0011]    Non-trusted applications are digitally unsigned applications (or application digitally signed by untrusted Certification Authorities—CAs) whose genuinity cannot be assessed on the terminal when they are installed and/or executed; these applications are thus a potential source of attacks to the terminal, because there is no information about them and it is not possible to perform any check. For these reasons, non-trusted applications are allowed to access only a limited subset of resources of the telecommunications terminal, i.e. of APIs (Application Program Interfaces), exposed by the operating system, namely APIs that are not considered dangerous. 
         [0012]    Trusted applications are instead digitally signed (by trusted CAs), and are allowed to access a wider set of exposed APIs. In particular, the APIs exposed by the operating system are grouped in different classes, according to a criterion of criticality of the accessed resources. The trusted, digitally signed applications are mapped onto a certain security level based on the CA that issued the digital certificate with which the application has been signed. Different security levels are defined, corresponding to different “root certificates”: an application is certified with respect to a certificate chain which refers to one of the root certificates present on the terminal. The security level to be assigned to the application is determined on the basis of the security level assigned to the root certificate used during the phase of verification. The security level assigned to the application determines the set of resources that the application can access, and the way the application can interact with them. In some cases, an application having been assigned a certain security level does not gain access to all the resources specified for that level, but only to those specified by the software vendor during the certification process. 
         [0013]    The use of the digital signature mechanism further allows implementing an application revocation mechanism, when the applications are compromised or violate specific security policies. For example, in case of availability of connectivity, the mobile terminal, before installing and/or executing an application, may ascertain whether the considered application has been revoked; this may be done by downloading and checking a Certificate Revocation List (CRL), or exploiting protocols like the Online Certificate Status Protocol (OCSP), so as to get an immediate response about the validity of the certificate tied to the signing key, and therefore of the related signed application. 
         [0014]    An example of implementation of the trust model can be found in EP-A-1361527 in which a method is described for loading an application into a device, and generally for downloading applications into portable devices, typically mobile telephones. The method includes the steps of: downloading the application with a signature to the device; coupling the signature of the application to a predefined attribute certificate stored in the device; and installing the application together with said attribute certificate. Preferably, the signature of the application is coupled to a root certificate which in turn is linking the application to a predefined attribute certificate. 
         [0015]    Another example of implementation of the trust model can be found in WO 2006/017757 in which a method and an apparatus are disclosed for providing enhanced security using service provider authentication. In addition to authenticating an application signature against a root certificate stored on the network node, a first carrier identification associated with the application is compared to a second carrier identification. If the first and second carrier identifications match, then the application can be assigned to a trusted protection domain and granted permissions which provide privileged access to the network node. For example, the application can be granted permission to be installed and/or executed on the network node. Otherwise the application can be denied privileged access. Accordingly, a carriers applications will be only installed onto network nodes that are intended recipients of the applications. 
         [0016]    Still another example of implementation of the trust model can be found in US 2005/03398 in which a single machine has entities running in an untrusted environment and entities running in a trusted environment, the trustworthiness of the entities in the trusted environment is projected to the entities in the untrusted environment. This is applicable, for example, to Microsoft&#39;s Next Generation Secure Computing Base (NGSCB), where a regular operating system (e.g., the Windows operating system) hosts a secure operating system (e.g., the nexus). 
       SUMMARY OF THE INVENTION 
       [0017]    The Applicant has observed that the trust model discussed in the foregoing is affected by some problems. 
         [0018]    The certification of applications by CAs has a non-negligible cost; thus, only those software producers/vendors capable of sustaining the certification costs will more likely be able to stay on the market (i.e., to offer powerful applications capable of accessing the most interesting APIs exposed by the operating systems of the mobile terminals). In this respect, it should be observed that the costs for having software applications certified by CAs are high also because it is not sufficient to have an application certified the first time it is put on the market: the certification needs to be repeated for each new release of the application, even if the changes are few or if a service pack or an application patch is released by a vendor. 
         [0019]    The problem of certification costs is particularly felt in the case of open-source software: the Applicant believes that it would be important that also open source-software applications may gain access to all the APIs and resources of operating systems, but the adoption of the above-described trust model, based on certification by CAsm may render this impossible, because it is not clear who will sustain the costs of the certification. 
         [0020]    Another problem of the trust model resides in the application revocation mechanism mentioned above. The revocation of an application could or should be authorized by several players involved within the trust model, like mobile phone users, software producers/vendors, network operators, mobile terminals manufacturers, and this complicates the design of the process and the assignment of the different roles and responsibilities. Legal issues are also involved, due to the different legislations in different countries: this may make it difficult to create a unique framework globally recognized and legally supported by the different countries adapted to offer a homogenous service profile. 
         [0021]    Still another problem of the trust model is that a software application is assigned a certain security level based on a set of standard tests, involving a static analysis of the application code (i.e., an analysis that does not consider what the application would actually do when running in the real environment). However, this static analysis may not be very effective: it cannot reconstruct and evaluate all the possible execution paths of the application. For this reason, some certification processes, like Symbian Signed, require a declaration from the software producer about the non-malicious behavior of the application. The situation is even more complex when software vulnerabilities are considered (bugs of software applications that may be exploited by the malware for propagating and making damages). Determining, through a static analysis, the presence of vulnerabilities is nowadays a challenging problem. Known solutions like Java, Symbian Signed, Microsoft M2M provide for a static assignment of a security level to the applications, determined during the certification phase. This kind of certification, as well as other types like Common Criteria or ITSEC (Information Technology Security Evaluation Criteria) certification, does not prevent the application from containing serious vulnerabilities which can be exploited by malicious software to perform attacks. Moreover, the certification does not change even if a critical vulnerability is determined and one or more exploits have been released. This static assignment is considered by the Applicant a strong limitation, both for the users (restrictions on the usability of the software applications) and for the business models that can be implemented. 
         [0022]    In view of the state of the art outlined in the foregoing, the Applicant has tackled the problem of implementing a security scheme not affected by the problems and limitations discussed above. 
         [0023]    In particular, the Applicant has tackled the problem of increasing the security of the application layer in telecommunications terminals having an open operating system. 
         [0024]    The Applicant has found that the problems evidenced by the known trust model can be overcome by providing a framework adapted to assign to software applications, that are installed and, possibly, executed by the telecommunications terminals, levels of security susceptible of varying in time, and by providing a framework adapted to dynamically manage the assigning of the levels of security to the applications. 
         [0025]    In particular, the Applicant has found that the levels of security can be assigned based on a reputation of the software applications. By reputation of a software application there is meant the degree of trust of the software application. The reputation, i.e. the degree of trust of a software application, may be calculated based on information gathered from a plurality of information sources; the information useful for calculating the reputation of a software application may include information about number and gravity of discovered vulnerabilities, analysis of the software application code (executable and, possibly, source code), existence of exploits of the discovered vulnerabilities, time to release of patches, and the like. 
         [0026]    For the purposes of the present invention, by “vulnerability” there is meant a weakness in a data processing system, allowing an attacker to violate the integrity, confidentiality, access control, availability, consistency or audit mechanism of the data processing system, or the data and/or applications it hosts. Vulnerabilities may result from bugs or design flaws in the system. A vulnerability can exist either only in theory, or could have a known exploit. Vulnerabilities are particularly critical when the program containing the vulnerability operates with special privileges, performs authentication or provides easy access to user data or facilities. 
         [0027]    The dynamic calculation of the level of security of the software applications may be delegated to a server entity, operating on behalf of the users of the telecommunications terminals. 
         [0028]    According to an aspect of the present invention, a system as set forth in appended claim  1  is provided. 
         [0029]    The system comprises:
       at least one telecommunications terminal having data processing capabilities, the telecommunications terminal being susceptible of having installed thereon software applications, wherein each software application has associated therewith a respective indicator adapted to indicate a level of security of the software application, said level of security being susceptible of varying in time;   a software agent executed by the at least one telecommunications terminal, said software agent being adapted to conditionally allow the installation of software applications on the telecommunications terminal based on the respective level of security;   a server in communications relationship with the software agent, said server being adapted to dynamically calculate the level of security of the software applications, and to communicate to the software agent the calculated level of security of the software applications to be installed on said telecommunications terminal.       
 
         [0033]    For the purpose of the present invention, by “level of security” of a software application there is intended a degree of trust that can be attributed to the software application, which determines the extent to which a telecommunications terminal allows access to its resources (APIs of the operating system). 
         [0034]    According to a second aspect of the present invention, a telecommunications terminal as set forth in claim  19  is provided, having data processing capabilities, and being susceptible of having installed thereon software applications, wherein each software application has associated thereto a respective indicator adapted to indicate a level of security of the software application. The telecommunications terminal comprises a software agent, adapted to be executed by the telecommunications terminal, said software agent being adapted to conditionally allow the installation of software applications on the telecommunications terminal based on the respective level of security, and to receive from a server updated levels of security of the software applications to be installed on said telecommunications terminal. 
         [0035]    According to a third aspect of the present invention, a system as set forth in appended claim  26  is provided, comprising a server adapted to communicate with at least one telecommunications terminal having data processing capabilities, wherein the telecommunications terminal is susceptible of having installed thereon software applications, each software application having associated therewith a respective indicator adapted to indicate a level of security of the software application, said level of security being susceptible of varying in time, said server being adapted to dynamically calculate the level of security of the software applications, and to communicate to the software agent the calculated level of security of the software applications to be installed on said telecommunications terminal. 
         [0036]    According to a fourth aspect of the present invention, a method as set forth in appended claim  36  is provided, comprising conditionally allow an installation of a software application on a telecommunications terminal based on the a level of security of the software application. Said level of security is susceptible of varying in time, and the method further comprises having the telecommunications terminal receive an updated level of security of the software application by a server in communications relationship with the telecommunications terminal. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0037]    The features and advantages of the present invention will be made apparent by reading the following detailed description of an embodiment thereof, provided merely by way on non-limitative example, description that will be conducted making reference for better clarity to the attached drawings, wherein: 
           [0038]      FIG. 1  schematically shows, in terms of functional blocks, the architecture of a system according to an embodiment of the present invention; 
           [0039]      FIG. 2  schematically shows, in terms of functional blocks, the structure of a trust provider component of the system of  FIG. 1 ; 
           [0040]      FIG. 3  schematically shows, in terms of functional blocks, the structure of a client component of the system of  FIG. 1 , resident on a terminal; 
           [0041]      FIGS. 4A ,  4 B and  4 C show a simplified flowchart illustrating the main actions performed by the client component and the trust provided component in case of installation of a new software application on the terminal; and 
           [0042]      FIG. 5  shows a simplified flowchart illustrating the main actions performed by the client component and the trust provided component in case a software application installed on the terminal is launched. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0043]    Making reference to the drawings, in  FIG. 1  the architecture of a system according to an embodiment of the present invention is schematically shown, in terms of functional blocks. 
         [0044]    The system is comprised of a trust provider component  105 , operating as a server in respect of several client components  110 , resident on mobile telecommunications terminals  115 - 1 ,  115 - 2 ,  115 - 3 ,  115 - 4 ,  115 - 5  of users. 
         [0045]    The mobile communication terminals are for example mobile phones, PDAs (Personal Digital Assistants), smart phones, adapted to the use in mobile telecommunications network, particularly mobile telephony networks like GSM (Global System for Mobile communications), GPRS (General Packet Radio System), EDGE (Enhanced Data rate for GSM Evolution) or UMTS (Universal Mobile Telecommunications System) networks. It is however pointed out that although in this description reference is made to mobile communications terminals, this is not to be construed as a limitation of the present invention, which applies as well to wired telecommunications terminals. 
         [0046]    The generic mobile terminal  115 - 1 ,  115 - 2 ,  115 - 3 ,  115 - 4 ,  115 - 5  has installed thereon an open operating system, like Windows Mobile, Symbian, or SavaJe, that controls the operation of the mobile terminals and allows the installation on the mobile terminals of third-party software applications. These software applications that may be installed on the mobile terminal may access the resources of the mobile terminal through APIs exposed by the operating system (APIs correspond to resources of the mobile terminal, thus hereinafter the terms “API” and “resource” will be regarded as synonyms). 
         [0047]    In particular, the APIs exposed by the operating system are grouped in different classes, corresponding to different level of relevancy of the APIs for the mobile terminal security. 
         [0048]    The software applications to be installed and executed on the mobile terminal have an associated security or trust level, that determines the set of APIs (one or more classes) that the application can access, and the relating access modality. 
         [0049]    Typically the security or trust level is one of a plurality of greater that two values, corresponding to three of more sets of APIs that the application can conditionally access. 
         [0050]    Examples of access modalities are the “allow always” modality, the “blanket” modality, the “one shot” modality and the “session” modality. In the “allow always” modality, the access request to a resource (i.e., to an API) by the software application is essentially transparent for the user, without requesting any direct interaction with the user (direct interactions may be through a prompt or the Graphical User Interface—GUI). In the “blanket” access modality, the software application may again access the resource in a way transparent to the user, exception made for the first time that the application requests access to the resource: in this case, an explicit authorization by the user is required; once the authorization is granted, it is considered permanent, and the successive access requests to the resource are implicitly considered authorized. In the “one shot” modality, each time the application requests the access to the resource, the user has to authorize it. In the “session” modality the access to the resource needs the authorization by the user; however, once the authorization is granted, it is considered valid for the whole session, i.e. until the execution of the application is terminated or the terminal is kept on; at the next invocation of the application, or at the next terminal power up, a new authorization by the user will be necessary to grant access to the resource. 
         [0051]    According to an embodiment of the present invention, the security level that is assigned to the generic software application intended to be installed and, possibly, successively executed on the mobile terminals  115 - 1 , . . . ,  115 - 5  is not static, i.e. it is not determined once and for all, as normally occurs during the application certification process, but it is intended to vary dynamically. 
         [0052]    In particular, the trust provider  105  acts on behalf of the users of the mobile terminals  115 - 1 , . . . ,  115 - 5 , and contributes to maintaining the integrity of the mobile terminals, by dynamically determining the appropriate security level to be assigned to the software applications intended to be installed or already installed on the mobile terminals  115 - 1 , . . . ,  115 - 5 , and communicating to the mobile terminals the updated security level of the software applications that are installed/to be installed thereon. 
         [0053]    The role of the trust provider  105  may be played by the operator of the mobile telecommunications network of which the users of the mobile terminals  115 - 1 , . . . ,  115 - 5  are subscribers. In fact, the mobile network operator already acts as a security provider for its users, in terms of authentication, channel encryption, and privacy protection. Moreover, it has the necessary technological and managing skills, it is trusted by the users, who already have signed contracts for the access to the mobile network, and it has resources and platforms, both on the network side and on the mobile terminal side, which may be advantageously exploited for realizing a security framework. 
         [0054]    The trust provider  105  is in communications relationship with the mobile terminals  115 - 1 , . . . ,  115 - 5 . Communications between the trust provider  105  and the mobile terminals  115 - 1 , . . . ,  115 - 5  may in particular take place OTA (Over The Air), exploiting the mobile telecommunications network resources, for example via SMS messages and/or MMS messages, and/or via a packet-based (e.g., GPRS) connection over an IP network. Preferably, the communications between the trust provider  105  and the mobile terminals  115 - 1 , . . . ,  115 - 5  are protected, for example using a digital signature mechanism (e.g., signed XML). 
         [0055]    The trust provider  105  is also in communications relationship with external information sources, globally denoted  120 , adapted to provide information useful to the trust provider  105  for dynamically determining, i.e. keeping updated the security level of the monitored software applications. In particular, and merely by way of example, the external information sources  120  may include the CERT (Computer Emergency Response Team, http://www.cert.org/), denoted as  120 - 1 , which is a center of Internet security expertise, located at the Software Engineering Institute, a federally funded research and development center operated by Carnegie Mellon University, devoted to study Internet security vulnerabilities, research long-term changes in networked systems, and develop information and training to help improve security; another exemplary external information source is OVAL (Open Vulnerability and Assessment Language, http://oval.mitre.org/), denoted as  120 - 2 , which is a standard language and methodology used to represent configuration information of systems for testing, aimed at analyzing the system for the presence of specified machine state (vulnerability, configuration, patch state, etc.). Further exemplary external information sources are the CVE (Common Vulnerabilities and Exposures, http://cve.mitre.org/), denoted as  120 - 3 , which is a standardized dictionary for all the publicly known vulnerabilities and security exposures, the software vendors bulletins, denoted as  120 - 4 , where the software producers and vendors publish the detected vulnerabilities of their software applications, possibly together with patches or work-around resolving the problem, and the software certification laboratories, i.e. the CAs, globally denoted as  120 - 5 , which are in charge of testing and certifying the applications, according to well known schemes (such as Symbian Signed, Microsoft Mobile-2-Market or OMTP framework). 
         [0056]    The trust provider  105  may also be in communications relationship with one or more other trust providers  105 - 1 ,  105 - 2 , for example run by different mobile telecommunications network operators, in order to share information relevant to dynamically and timely determining the security level of the monitored software applications. This kind of data can be shared without any privacy concern, because security levels are tied to applications and not to users. 
         [0057]    In  FIG. 1 , the arrows between pairs of mobile terminals  115 - 1 , . . . ,  115 - 5  are intended to represent direct peer-to-peer telecommunications channels between the mobile terminals, for example, but not limited to, short-range communications channels, like Bluetooth, ZigBee, NFC and the like, or full IP channels over GSM/GPRS/UMTS/HSDPA (High Speed Downlink Packet Access)/WiFi, if available; in a preferred embodiment of the present invention, the mobile terminals, exploiting these direct, peer-to-peer communications channels may share the information relating to the security level of the software applications installed and possibly running thereon, even without the need to establish a connection with the trust provider  105 . This contributes to increasing the efficiency of the security framework and provides better bandwidth consumption. 
         [0058]    Passing now to  FIG. 2 , the structure of the trust provider  105  is depicted in greater detail, in terms of the main functional blocks. 
         [0059]    The trust provider  105 , which acts as a server component in respect of the client components  110  installed and running on the mobile terminals, includes a front end  205  and a back end  210 . 
         [0060]    The front end  205  includes communication interfaces, denoted globally  215 , for the communication with the clients  110  resident on the mobile terminals; such communication interfaces  215  include for example an SMS interface, an MMS interface, an IP interface, a broadcast channel interface (for instance to send information over the Cell Broadcast channel on GSM/GPRS/UMTS networks). The front end  205  of the trust provider  105  also comprises an information publishing interface  220 , e.g. a web server accessible by third parties, like the users of the mobile terminals and the other trust providers, through web browsers; through the information publishing interface  220 , the trust provider  105  publishes and makes accessible to third parties information like: the methodology adopted by the trust provider  105  to calculate the security level of the monitored software applications (this may take the form of a Security Level Evaluation Statement—SLES, a document intended to declare the security level evaluation methodology adopted); a list of monitored software applications with their current security levels, and, possibly, historical data concerning how the security level of the applications varied in time; past events relevant to the establishment of the security level of the monitored software applications. The access to this kind of information may be subject to an authentication process, in order to make the data available only to the authorized users and agents. 
         [0061]    The back end  210  comprises a static or binary analyzer module  225 , adapted to perform a static, i.e. binary analysis of the code of the software applications; a vulnerability analyzer module  230  is also provided, which, exploiting the information gathered from the external information sources  120 , is adapted to analyze the vulnerabilities of the software applications. A security level evaluator module  235  is configured to receive the outputs of the binary analyzer module  225  and the vulnerability analyzer module  230 , as well as to gather information from the external information sources  120 , particularly from software producer/vendor bulletins  120 - 4 , from CAs  120 - 5  and from other trust providers  105 - 1 ,  105 - 2  and, applying a predetermined metric (specified in the SLES published and maintained by the trust provider  105 ), calculates the security level to be assigned to each monitored software application. The security level is typically selected by the security level evaluator module among three or more levels. A software application database  240  is configured to store a list of all the software applications monitored by the trust provider  105 , and the corresponding security levels (preferably, in addition to the current security level, the past security levels are also stored, so that the history of the software applications can be appreciated). A user database  245  stores the identifier and other details (e.g., details necessary for establishing communications with the users&#39; mobile terminals or for billing purposes) of users that are subscribers to the trust provider  105 , and, for each user, a list of software applications that are installed on the users mobile terminal. 
         [0062]    In  FIG. 3  the structure of the client component  110  installed and running on the generic mobile terminal is depicted, in terms of the main functional blocks. 
         [0063]    The client component  110  is a software agent running on the mobile terminals. The client component  110  includes a client/server communications module  305 , adapted to manage the communications between the client component  110  and the server component represented by the trust provider  105 . A peer-to-peer communications module  310  is preferably provided, adapted to manage the direct communications with other mobile terminals, exploiting for example short-range communications channels like Bluetooth, ZigBee, NFC, and the like, or full IP communications channels, over GSM/GPRS/UMTS/HSDPA. Moreover, a broadcast communications module  315  is also provided, in order to get information through the broadcast radio channels, such as the Cell Broadcast in the GSM/GPRS/UMTS network. The communications modules  305 ,  310 , and  315  form a front end  320  of the client component  110 . 
         [0064]    The client component  110  also includes a monitor layer  323 . The monitor layer  323  includes an application installation monitor module  325 , adapted to detect the launching of activities related or leading to the installation of new software applications on the mobile terminal. The monitor layer  323  also includes an application execution monitor module  330 , adapted to detect the launching of applications installed on the mobile terminal. A kernel module  335  is provided, that communicates with the application installation monitor module  325  and the application execution monitor module  330 , and with a local database  340  configured to contain information like the current security level of the software applications installed on the mobile terminal, and the digital certificates of the trust provider  105  (possibly, the digital certificates of trust providers, like the trust providers  105 - 1  and  105 - 2 , that are federated with the trust provider  105  are cross-certified; in this way, information about the security levels of software applications obtained, through the peer-to-peer communications channels, from mobile terminals that are subscribers to the other trust providers  105 - 1 ,  105 - 2  of the federation may be validated and recognized as both genuine and approved by the user&#39;s trust provider). 
         [0065]    The kernel module  335  also interacts with a security level updater module  337 , which manages the updating of the security levels of the software applications, establishing communications with the trust provider  105  (through the client/server communications module  305 ) and/or with other mobile terminals (through the peer-to-peer communications module  310 ), or just receiving updated information by means of broadcast radio channels, such as the Cell Broadcast (through the broadcast communication module  315 ). 
         [0066]    The kernel module  335  may also communicate with external information sources (where by “external” there is meant external to the client component  110 , but resident on the mobile terminal), like an Intrusion Detection System (IDS)  345  and other security tools  350 , for example an anti-malware software or a personal firewall installed on the mobile terminal. 
         [0067]    In the following, the operation of the security framework will be explained in detail. 
         [0068]    The trust provider  105  maintains updated a dynamic level of security of the software applications installed on the mobile terminals of the user subscribers thereto. 
         [0069]    Referring to the simplified flowchart of  FIGS. 4A ,  4 B and  4 C, let it be assumed that, at a certain time, a new software application is to be installed on the mobile terminal: in this case the event is detected by the application installation monitor module  325  (block  405 ), which notifies it to the kernel module  335  (block  410 ). The kernel module  335 , upon receiving the notification from the application installation monitoring module  330 , looks into the local database  340  to ascertain whether the specified software application is already listed therein (meaning that the application is already monitored), and, in the affirmative case, it checks whether the security level of the software application is sufficiently up to date (decision block  415 ). In the affirmative case (decision block  415 , exit branch Y), the kernel module  335  assesses whether the security level of the software application to be installed is sufficiently high, i.e. it is not below a predetermined, minimum security level (decision block  420 ): in the affirmative case (decision block  420 , exit branch Y), the kernel module authorizes the installation of the application (block  425 ), which will therefore be allowed; in the negative case (decision block  420 , exit branch N), the kernel module  335  may prevent the installation of the software application. It should be noted that the predetermined minimum security level may be optional: if not configured, the application will be always installed on the mobile terminal, and just limited, in terms of available mobile terminal APIs, by its corresponding security level. 
         [0070]    In case the specified software application to be installed is not listed in the local database  340 , or, even if it is listed, the security level thereof is not sufficiently up to date (decision block  415 , exit branch N), the kernel module  335  invokes the security level updater module  337  to inform the server component that a new application is going to be installed on the mobile terminal, and to get the (updated) security level for the considered application (block  435 ). 
         [0071]    The security level updater module  337  tries to establish a connection with the trust provider  105  (block  440 ) and, if the connection is successfully established, it informs the trust provider  105  that the installation of a new software application has been started on the mobile terminal. It also asks the trust provider  105  for the updated security level related to the specified software application (block  445 ). 
         [0072]    The trust provider  105  receives the request from mobile terminal (block  450 ), updates the user database  245  adding the specified software application to the list of applications installed on the mobile terminal of the user (block  455 ), and then provides to the security level updater module  337  the current security level for the specified software application (block  460 ). In case the specified software application is not in the list of the monitored software applications, the trust provider can start a procedure for gathering information on that software application, and for calculating the corresponding security level. According to the specific metric adopted by the trust provider, the security level computation for a new application (i.e., an application not already monitored) may require time, and thus it may happen that it cannot be completed in real-time. In these cases, the trust provider can return a conservative security level (for instance the lower value), in order to limit the set of the APIs available to the application, at least for the time needed to complete the full security level computation. In these cases, the trust provider may also ask other federated trust providers for the security level related to the specific application. 
         [0073]    The updated security level for the specified application is passed to the kernel module  335 , and stored into the local database  340  (block  465 ). 
         [0074]    The kernel module  335  can now assess the security level of the software application to be installed, and allows or prevents the installation depending on whether the security level of the application is below a predetermined, minimum security level (connector C, jumping back to decision block  420 ). 
         [0075]    The security level updater module  337 , in case the connection with the trust provider  105  cannot be established, or in addition to establishing a connection with the trust provider  105 , may try to establish a connection with other mobile terminals, using the peer-to-peer communications module  310 . If the security level updater module  337  cannot establish any kind of connection (for instance because the mobile terminal is offline), according to a preconfigured policy, the kernel module  335  may assign either a conservative security level (for instance the admissible lower level) or prevent the software installation until an updated security level for the considered application will be available. 
         [0076]    Referring to the simplified flowchart of  FIG. 5 , let it now be assumed that, at a certain time, a software application installed on the generic mobile terminal  115 - 1  is launched. The application execution monitor module  330  detects this event (block  505 ), and notifies it to the kernel module  335  (block  510 ). The kernel module  335 , upon receiving the notification from the application execution monitor module  330 , checks if the application is already installed and monitored, i.e. if the application is already present in the local database  340 . If the application is not present, the event is handled as an installation of a new application, as described in connection with  FIGS. 4A to 4C . If instead the application is present in the local database  340 , the kernel module  335  retrieves the associated security level from the local database  340 . If the security level is sufficiently up to date, the kernel module  335  grants the execution and the API access to the application, based on its security level. Conversely, if the security level is not sufficiently up to date, the kernel module  335  invokes the security level updater module  337  in order to refresh the security level information stored in the database  340  (block  515 ). 
         [0077]    The security level updater module  337  tries to establishes a connection with the trust provider  105  (block  520 ), and if the connection is established it asks to the trust provider  105  to provide the updated security level for the specified software application (block  525 ). The security level updater module  337 , in case the connection with the trust provider  105  cannot be established, or in addition to establishing a connection with the trust provider  105 , may try to establish a connection with other mobile terminals, using the peer-to-peer communications module  310 . 
         [0078]    The trust provider  105  receives the request from the mobile terminal, and provides thereto the current security level for the specified software application (block  530 ), taking it from the application database  240 . Possibly, the trust provider  105 , upon ascertaining that the specified software application is not in the list of software applications installed on the mobile terminal of that user, adds it to such a list (stored in the user database  245 ). In case the connection with the trust provider cannot be established, or in addition thereto, the mobile terminal may receive an updated security level for the specified application from one or more other mobile terminals; in this case, the security level updater module  337  may be adapted to assess which is the more recent security level for that software application: this may for example be done by associating, with the security level, an indication of the date and time the security level was last updated. 
         [0079]    The updated security level is passed to the kernel module  335 , and stored into the local database  340  (block  535 ). 
         [0080]    If the security level updater module  337  cannot establish any kind of connection (for instance because the mobile terminal is offline), according to a preconfigured policy, the kernel module  335  may assign either a conservative security level (for instance the admissible lower level) or prevent the software execution until an updated security level for the considered application will be available. 
         [0081]    Based on the security level, the kernel module  335  grants to the software application that has been launched conditional access to the resources of the mobile terminal, i.e. to the APIs exposed by the operating system associated to the specific application security level, according to the trust model implemented. 
         [0082]    When a software application is uninstalled from the mobile terminal of a user, this event is communicated to the trust provider  105  (as soon as a network connection is detected and available), which then deletes the specified software application from the list of software applications installed on the mobile terminal of that user, stored in the user database  245 . 
         [0083]    The trust provider  105  may also implement push-type update mechanisms of the local database  340  of the mobile terminals (for instance by means of SMS, MMS, WAP push messages, Cell Broadcast messages), so as to provide to the client components  110  running on the mobile terminals updated security levels of the software applications installed thereon. Also, the client components, in addition to inquiring the trust provider  105  when a software application is launched or is being installed on the mobile terminal, may periodically contact the trust provider  105  to get updated security levels for the software applications installed thereon. In alternative or in addition to the periodical updating, the client component may operate on a sample basis, selecting a subset of applications among those installed on the mobile terminal (for instance the most frequently used) and for them requesting the updated security level. 
         [0084]    The client components  110  resident on the mobile terminals may also notify to the trust provider  105  anomalous events, detected for example by IDS or anti-malware tools  345  or  350  installed on the mobile terminal. Upon receiving such notifications, the trust provider may take the steps necessary to identify which of the software application(s) installed on the mobile terminal caused the anomalous events (for instance correlating the anomalous events sent by different users), and put the identified applications in a list of applications that need to be more carefully analyzed; these applications may for example be tested in depth in laboratory. 
         [0085]    Hereinafter an example of a method implemented by the trust provider  105  for calculating the security level of the software applications is discussed. It is pointed out that the calculation method described below is merely exemplary, and not to be construed limitatively for the present invention, because several alternative methods are possible. 
         [0086]    The binary analyzer module  225  is adapted to analyze statically the binary code of the generic software application. The static analysis is performed statically analyzing the executable code, without analyzing all the possible dynamic behaviors or the execution paths of the software application. The static analysis may in particular ascertain the type of the APIs that the software application invokes, details of the installation of the software application (e.g., if the autorun feature is exploited), the nature of the accessed data. Based on the analysis performed, the binary analyzer module  225  may assign a value to a parameter or set of parameters AS to be passed to the security level evaluator module. 
         [0087]    The vulnerability analyzer module  230  is adapted to assess the vulnerabilities of a software application whose security level is to be evaluated. The vulnerability analyzer module  230  is adapted to retrieve information useful for assessing the vulnerabilities from external information sources like the CERT, the OVAL/CVE, the bulletins of the software producers and vendors, the software certification authorities. The vulnerability analyzer module  230  is adapted to provide to the security level evaluator module  235  an indication of the overall number of vulnerabilities found for the considered software application, the level of criticality of each encountered vulnerability, and an estimation of when the next criticality will be found, by means of statistical and predictive analyses. Based on the analysis performed, the vulnerability analyzer module  230  may assign a value to a parameter or set of parameters AV to be passed to the security level evaluator module. 
         [0088]    Another parameter that is useful to the security level evaluator module for establishing the security level of an application is the reaction time of the software producer/vendor to the detection/publication of a new vulnerability, i.e. the indication of the time needed by the software producer/vendor for finding a remedy to the detected/published vulnerability. A parameter or set of parameters TR may be defined whose value depends on the time needed for the publication of a remedy after a vulnerability is detected/published, the efficacy of the published remedy, workaround or patch, the criticality of the vulnerability to which the remedy has been published. 
         [0089]    The security level evaluator module may additionally assign a value to a parameter or set of parameters AF defining the reliability of the software producer/vendor; in this way, enterprises that, in their history, have proved to be capable of producing/distributing secure, reliable software products affected by less vulnerabilities may be privileged. 
         [0090]    In the process of evaluating the security level of a certain software application, the trust provider  105  may further take into account the presence of any certification, declaration or assurance, issued by a recognized authority, such as those related to Symbian Signed, Microsoft Mobile2Market, Common Criteria, or ITSEC. The presence of such a certification may affect the value of a parameter or set of parameters AC. 
         [0091]    A further source of useful information for determining the security level of a software application are the notifications coming from the mobile terminals themselves, for example anomalies detected by anomaly detection or intrusion detection tools resident on the mobile terminals. As mentioned in the foregoing, when an IDS or an anti-malware software tool resident on the generic mobile terminal detects an anomaly behavior, or just an intrusion, by a malware, they may signal it to the client component  110 , which then notifies the event to the trust provider  105  (possibly conditioned to the authorization of the mobile terminal user). The trust provider, knowing which are the software applications that are installed on the mobile terminal of that user, can carry out an analysis to identify, by correlating the information possibly coming from different mobile terminals, which is the software application(s) that most likely caused the anomaly. The trust provider may also perform more detailed analysis such as a static analysis of the code or blackbox analysis (i.e., analysis that do not make assumptions on the implementation choices made during the development of a software application, limiting to observe and analyze the inputs and outputs of the application). This type of analysis affects the value of a parameter or set of parameters AD. 
         [0092]    In the evaluation of the security level to be assigned to a software application, the trust provider may also set a time window for the analysis, for example considering the number of vulnerabilities detected and published in the last predetermined number (e.g., twelve) months. The set time window is specified as the value of a parameter t. 
         [0093]    Using the above discussed evaluation elements, the metric adopted by the security level evaluation module for calculating the security level of a software application may be expressed as: 
         [0000]        SL   APP ( t )=ƒ( AS,AV,TR,AF,AC,AD,t ) 
         [0000]    where ƒ( ) denotes a function having a predetermined form, and AS, AV, TR, AF, AC, AD and t are parameters that correspond to the evaluation elements described above. 
         [0094]    Depending on the case, the trust provider may apply one among a plurality of functions ƒ( ), for example based on the type of user. For example, a function ƒ Consumer ( ) should be defined for consumer users that do not want to give up the possibility of installing and executing a generic software application on their terminals. Another function ƒ Enterprise ( ) should be defined for users employees of a customer enterprise, having stricter security standards. 
         [0095]    A possible function ƒ( ) is a weighted sum of the parameters: 
         [0000]    
       
         
           
             
               
                 SL 
                 APP 
               
                
               
                 ( 
                 t 
                 ) 
               
             
             = 
             
               
                 
                   
                     
                       
                         
                           ω 
                           AS 
                         
                          
                         
                           AS 
                            
                           
                             ( 
                             t 
                             ) 
                           
                         
                       
                       + 
                       
                         
                           ω 
                           AV 
                         
                          
                         
                           AV 
                            
                           
                             ( 
                             t 
                             ) 
                           
                         
                       
                       + 
                       
                         
                           ω 
                           TR 
                         
                          
                         TR 
                          
                         
                           ( 
                           t 
                           ) 
                         
                       
                       + 
                     
                   
                 
                 
                   
                     
                       
                         
                           ω 
                           AF 
                         
                          
                         
                           AF 
                            
                           
                             ( 
                             t 
                             ) 
                           
                         
                       
                       + 
                       
                         
                           ω 
                           
                             A 
                              
                             
                                 
                             
                              
                             C 
                           
                         
                          
                         A 
                          
                         
                             
                         
                          
                         
                           C 
                            
                           
                             ( 
                             t 
                             ) 
                           
                         
                       
                       + 
                       
                         
                           ω 
                           
                             A 
                              
                             
                                 
                             
                              
                             C 
                           
                         
                          
                         A 
                          
                         
                             
                         
                          
                         
                           D 
                            
                           
                             ( 
                             t 
                             ) 
                           
                         
                       
                     
                   
                 
               
               
                 
                   ω 
                   AS 
                 
                 + 
                 
                   ω 
                   AV 
                 
                 + 
                 
                   ω 
                   TR 
                 
                 + 
                 
                   ω 
                   AF 
                 
                 + 
                 
                   ω 
                   
                     A 
                      
                     
                         
                     
                      
                     C 
                   
                 
                 + 
                 
                   ω 
                   
                     A 
                      
                     
                         
                     
                      
                     C 
                   
                 
               
             
           
         
       
     
         [0096]    where the weights may be differentiated based on the type of users: 
         [0000]      Ω Consumer =(ω′ AS ,ω′ AV ,ω′ TR ,ω′ AF ,ω′ AC , ω′ AD ) 
         [0000]      Ω Enterprise =(ω″ AS ,ω″ AV ,ω″ TR ,ω″ AF ,ω″ AC , ω″ AD ) 
         [0097]    these being two sets of weight factors specific for consumer users and for enterprise users, respectively. 
         [0098]    The present invention overcomes the problems of current static certification systems, in terms of high costs and organization. 
         [0099]    Thanks to the present invention, software applications are assigned security levels that may vary dynamically in time, being periodically re-calculated by means of a well recognized evaluation metric so as to track changes in the security aspects of software applications; this allows implementing policies that rewards software applications that have demonstrated on the field their security. 
         [0100]    Moreover, the present invention contributes to reduce the security risks associated to both malware and exploitable applications. Once a malware is detected, the corresponding security level is an information for the agent on the mobile terminal to prevent the application from running (and possibly to delete it). In case of an exploitable application, the security level is lowered until a work around or a patch will be released, making the application executable, but at the same time limiting is the resources made available on the mobile terminal. This limit is put in order to also reduce the risk of damages produced by malware which exploits the application vulnerability. It should be noted that, within this period (up to the work around or the patch) the application is still available to users. 
         [0101]    The solution according to the present invention is very flexible, particularly in terms of the business models that can be set up; the costs for keeping the security level information available at the mobile terminal updated may for example be sustained by the trust provider, that may set up toll-free telephone numbers for the connection thereto by the mobile terminals of subscriber users; in case the role of the trust provider is played by the mobile network operator, these costs may be included in the service agreement with the users. 
         [0102]    The system according to the present invention enables the mobile telecommunications network operators to play a central role in the enforcement of security on the mobile terminals, and this is believed to be advantageous not only for the operators themselves (in terms of network protection), but also for the users, who can rely on a trusted counterpart having the technical and organizational skills. 
         [0103]    Another advantage of the system according to the present invention is that it does not exclude an important category of applications like those falling under the open source software category, because the software producers are not required to sustain high certification costs. 
         [0104]    The system according to the present invention can be easily integrated with existing solutions, based for example on the previously described trust model. 
         [0105]    The present invention has been herein described making reference to an exemplary and non-limitative embodiment thereof. Those skilled in the art will recognize that several modifications can be made to the described embodiments, for example in order to satisfy contingent needs , as well as several other embodiments are possible, without departing from the scope of protection set forth in the appended claims. 
         [0106]    For example, nothing prevents from implementing the software agent in the SIM to be operatively associated with the telecommunications terminal for its operation in the telecommunications network.