WO2007113709A1 - Method and apparatus for assigning an application to a security restriction - Google Patents

Method and apparatus for assigning an application to a security restriction Download PDF

Info

Publication number
WO2007113709A1
WO2007113709A1 PCT/IB2007/050934 IB2007050934W WO2007113709A1 WO 2007113709 A1 WO2007113709 A1 WO 2007113709A1 IB 2007050934 W IB2007050934 W IB 2007050934W WO 2007113709 A1 WO2007113709 A1 WO 2007113709A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
api
security
restriction
sandbox
Prior art date
Application number
PCT/IB2007/050934
Other languages
French (fr)
Inventor
Declan Patrick Kelly
Original Assignee
Koninklijke Philips Electronics N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics N.V. filed Critical Koninklijke Philips Electronics N.V.
Publication of WO2007113709A1 publication Critical patent/WO2007113709A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine

Definitions

  • the present invention relates generally to information security, and more particularly to method and apparatus for assigning an application to a security restriction.
  • Java programming language is an increasing popular software programming language because Java is independent from the underlying computing platform (processor and Operating System).
  • the source code of a Java program is compiled to byte code, which cannot be run by itself.
  • the byte code must be converted into machine code at runtime.
  • a JVM interprets the byte code to machine code that is compatible with the underlying computing platform.
  • the underlying computing platform, peripheral devices, and the software and data available to underlying computing platform are referred as resources.
  • a software application being executed on the computing platform can request to use the resources.
  • MHP offers a great opportunity to leverage the third party developers other than the CE product manufacturers to enhance the products, for instance, MHP offers an open middleware system allowing the third party to develop their applications to wide audience. But, it also creates the threat of malicious damage of the MHP device or unauthorized use of user private information by an untrusted application.
  • sandbox which can limit access to system resources can also be used in MHP application.
  • the sandbox creates an environment in which there are strict limitations on what system resources the applet can request or access. Sandboxes are used when executable code comes from unknown or untrusted sources and allow the user to run untrusted code safely.
  • the Java sandbox has been successful in establishing a level of trust in network computing, but it has also put narrow limits on what may be done for users with applets.
  • Unsigned applications that are untrusted by the device have only the basic set of rights, signed applications that are untrusted by the device also only have this basic set by default.
  • An application broadcaster can request additional permission to access specific resources by providing a signed "Permission Request File" along with the application, but it is no guarantee that the application will get the permissions. Normally, it is difficult for an end- user to explicitly grant an application these permissions.
  • a method for assigning an application to a security restriction comprising the step of: obtaining the information of an API required by the application; checking an attribute of the API; allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
  • an apparatus for assigning a security restriction to an application comprising: obtaining means for obtaining the information of an API required by the application; checking means for checking an attribute of the API; allocating means for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
  • a computer program product for assigning a security restriction to an application comprising: code for obtaining the information of an API required by the application; code for checking an attribute of the API; code for allocating the application to a security restriction when the attribute of the
  • API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
  • a non- authenticated application can provide more useful user features implemented by using a well-defined subset of available APIs.
  • the application By allowing the application to choose the API class to use, the user has more freedom than if the device only allowed the minimum set of 'safe' APIs.
  • FIG. 1 depicts a schematic diagram of a MHP basic architecture according to one embodiment of the present invention
  • FIG. 2 depicts a schematic structural diagram of multiple sandboxes according to one embodiment of the present invention
  • FIG. 3 depicts a flow chart of assigning a downloaded application to one of multiple sandboxes according to one embodiment of the present invention
  • FIG. 4 depicts a flow chart of Part A in Fig. 3 according to one embodiment of the present invention.
  • the same referential numerals are used to indicate the same, similar, or corresponding characteristics or functions.
  • FIG. 1 a schematic diagram of a MHP basic architecture according to one embodiment of the present invention.
  • the architecture of the MHP is defined in terms of three layers: resources 40, system software 30 and application(s) 10.
  • the application(s) 10 implements interactive services as software running in the MHP based device.
  • a MHP based device a HDD (High Density Disk) based Personal video Recorder (PVR) with Internet connectivity can be used to store broadcast content, user generated content and applications downloaded from Internet as well.
  • PVR Personal video Recorder
  • the API(s) 20 lies between the application(s) 10 and the system software 30.
  • the API 20 provides corresponding services to the application(s) 10, and the application(s) 10 accesses resources 40 only through the API(s) 20.
  • the resources 40 include hardware resources (for example, MPEG decoder, I/O device, CPU etc.) and software resource (for example, driver program etc.), which are representatives of hardware entities in the MHP platform.
  • the system software 30 brings an abstract view of the resources 40, and this middle layer isolates the application 10 and the resources 40, enabling portability of the application 10.
  • an Operating System can be as system software 30, Operating System may include Windows, Mac OS or Linux etc.
  • the Operating System may include a Java-enabled browser that allows Operating System to retrieve and display information and to run Java applet. Also, the system may include a Java Virtual Machine (JVM) to allow Operating System to execute a Java application.
  • JVM Java Virtual Machine
  • the system software 30 includes an application manager 31, which is part of the system software 30. It interacts with all applications 10.
  • the application manager 31 can be as a filter between downloaded code and the system software 30.
  • the application manager 31 includes an obtaining unit 312, a checking unit 314 and an allocating unit 316.
  • the obtaining unit 312 obtains the information of an API required by an application, and checking unit 314 checks the attribute of the API, for example, whether the API belongs to a security level, whether the API uniquely belongs to a security restriction, whether the API belongs to an overlap of two or more security restrictions, and whether the API belongs to an assigned security restriction of the application 10.
  • the allocating unit 314 allocates the application to a security restriction when the attribute of the API 20 indicates the API 20 only belongs to the security restriction.
  • the application manager 31 could further includes a determining unit 310 for determining the security level of the application(s) 10.
  • the application manager 31 could further include a blocking unit 318.
  • the blocking unit 318 blocks this part of the application corresponding to the API from running.
  • determining unit 310 may send its determination of security level to the checking unit 314 and/or the allocating unit 316. It is also understandable that the allocating unit 316 may send its allocation result to the checking unit 314.
  • the security restriction may be a sandbox in a JVM, and the security restriction could also be any similar function in ActiveX or Netscape login.
  • the desire of this invention can also be implemented by means of a suitably programmed computer provided with a computer program for assigning an application to a security restriction.
  • the computer program product for assigning an application to a security restriction comprises code for obtaining the information of an API required by the application, code for checking an attribute of the API, and code for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
  • Such a computer program product may be stored in a storage carrier, or may be available for downloading.
  • FIG. 2 a schematic structural diagram of multiple sandboxes of a CE device according to one embodiment of the present invention.
  • the architecture of the sandboxes are defined in terms of three security levels: low level, medium level and high level.
  • low level low level
  • medium level high level.
  • the device When an application is loaded to a device, the device must determine which security level the application belongs to. A number of methods can be considered to implement this determination.
  • the application is tagged with the security level so before running the application the device knows its corresponding security level, for example, the tag of the application indicates the source of the application, if the application is from the manufacturer of the CE device, its corresponding security level is high, and if the application is from the allies of the manufacturer or certain companies, its corresponding security level is middle, and if the application source is unknown, its corresponding security level is low.
  • the other way to implement the determination is that the application calls an API to indicate which security level it belongs to; or the device detects the security level from the APIs which have been used by the application.
  • Each sandbox consists of a set of APIs that applications running in the sandbox can use.
  • the sandboxes are (overlapping) API classes.
  • the APIs are grouped according to a predetermined rule so that a grouping of APIs represents a "safe" combination of APIs.
  • An application will be assigned to a sandbox when it accesses an API that is unique specific to that sandbox. This can be done dynamically, the application does not need to indicate which sandbox, it will be assigned to the sandbox when it accesses a restricted function associated with an API.
  • Sandbox A includes API 1 and API 2
  • sandbox B includes API 3 and API 4.
  • Sandbox C is a superset of Sandbox A
  • Sandbox D is a superset of Sandbox B and contains some overlap (API 7) with sandbox C.
  • Sandbox E is the complete set of APIs. In practice there will probably be a set of APIs that are accessible to all sandboxes.
  • the information used/created by an application within one sandbox will not be available to the same application within another sandbox. For example, files written by an application is tagged with the sandbox the application was running in. If the same application runs again in a different sandbox (at the same authentication level), it will not be able to read the files previously written.
  • sandboxes may be linked to different levels of authentication, some sandboxes require no authentication, some require authentication by a trusted source, and a special sandbox consisting of all APIs is only available to applications authenticated as being from the device manufacturer. For example, if an application gets a middle level of authentication from the device manufacturer, when the application requires the API2, the application will be assigned to the sandbox C, but not the sandbox A or the sandbox E. That means the accessing any APIs outside the sandbox C is prevented, the application can only access API 1, API 2, API 6 and API 7 within the sandbox C.
  • the authentication can be done as in MHP using public/private keys set by the device manufacturer.
  • the device includes the public key of the trusted source and can check that the application was signed with the corresponding private key.
  • the device will contain at least the public key of the device manufacturer to authenticate the application from the device manufacturer, which will have access to all APIs.
  • the APIs are grouped according to a pre-determined rule so that a grouping of APIs represents a safe combination of APIs. For instance, the manufacturer can create several pre-defined groups of APIs as different security restrictions on a MHP device, when an new application loaded to the MHP device, the device would determine security level of the application and detect which API the application require to address. If the device detects that the API required by the application uniquely belongs to one of the several pre-defined group of APIs, the device would assign the related security restriction to the application.
  • whether an application can access an API depends, not only on its security level, but also on what other APIs it has used instead of what APIs it will use.
  • the APIs are not explicitly grouped, the manufacturer only creates several rules for not grouping conflicting APIs into one security restriction on a MHP device, for instance, a rule depicts that API 1 and API 3 can not be grouped into one security restriction so if an application uses API 1 then it can no longer use API 3 and vice versa.
  • an application uses APIs which common to both sandbox C and sandbox D, then it is not restricted to either one.
  • EPG Electronic Programme Guide
  • Content Browser Content Browser
  • Photo- sharing application and Interactive Game.
  • all Internet access APIs are specific to sandbox C
  • all local storage APIs are specific to sandbox D
  • all other APIs are in the overlap between Sandbox C and sandbox D e.g. access to user commands from the remote control, graphics libraries to draw graphics on the screen.
  • EPG gets Electronic Programme Guide information from the Internet and presents it to the user and based on the user interaction can request some content to be recorded.
  • EPG may first access some APIs in the overlap of the sandbox C and sandbox D to display graphics on the screen or to get user input via the remote control or to access the user's public profile.
  • the application will be assigned to sandbox C. From that time on it can access the APIs that are specific to sandbox C and any APIs in the overlap with sandbox D.
  • Content application this application lets the user browse and navigate through content on the disc (e.g.
  • the application may first access some APIs in the overlap of the two Sandboxes e.g. to display graphics on the screen or get user input via the remote control or to access the user's public profile.
  • the Application accesses an API related to Local Storage (which is specific to sandbox D)
  • the application will be assigned to sandbox D. From that time on it can access only the APIs that are specific to sandbox D and any APIs in the overlap with sandbox C.
  • the files in local storage are tagged with the sandbox the application was running in so if the same application later runs in a different sandbox it cannot read information from the other sandbox.
  • Photo-sharing application this application allows the user to share photos from their local storage through the Internet, may first access some APIs in the overlap of the two Sandboxes e.g. to display graphics on the screen or get user input via the remote control or to access the user's public profile. If the application then accesses a Local Storage API then it will be assigned to Sandbox D. Later when the application tries to access an Internet Access API, it will be blocked (by the Application Manager) as these APIs are outside of
  • Sandbox D Similarly, if the application first accesses an Internet Access API then it will be assigned to Sandbox C. Later if it tries to access a Local Storage API then it will be blocked (by the Application Manager) because those APIs are outside of Sandbox C. To be able to use both the Internet Access APIs and the Local Storage APIs is not possible for an application with this level of authentication. It may be possible if the application has a higher level of authentication (e.g. from the device manufacturer).
  • the Interactive Game Application does not need to access the local storage or the Internet.
  • This application will access APIs to display graphics on the screen and take remote control commands from the user.
  • This application will only use APIs in the overlap between Sandbox C and Sandbox D and will never be assigned to either, however this is no security problem in this case - the application can only perform actions that an application assigned to Sandbox C could do or an application assigned to Sandbox D could do, it can never do things that an application in Sandbox C or Sandbox D could not do.
  • the application manager may restrict access to an API because the application has used an API from another sandbox, thus the choice of whether an application can access an API is dynamic. It is understandable that there could be only one security level with two or more security restriction(s) (overlapped or not).
  • FIG. 3 a flow chart of assigning a downloaded application to one of multiple sandboxes according to one embodiment of the present invention.
  • step S310 depicts an user accessing the Internet with a Java enabled browser or other application
  • Security for the JVM associated with the browser is determined initially by browser policies that were programmed into the browser by the manufacturer.
  • step S320 depicts downloading a Java application.
  • step S325 depicts determination of the security level of the application based on the authentication of the application, for example, middle level.
  • the device can terminate an application that violates the security level.
  • step S330 the application manager obtains the information of the API required by the application.
  • Step S340 depicts the application manager checking if the API is inconsistent with the applications current security level. If the application has already been assigned to a security level and if the requested API is within this security level, for example, the API belongs to a security restriction of this security level, then it is consistent, otherwise it is inconsistent.
  • step S370 depicts the application manager blocking the applications access to this API.
  • step S395 to detect whether the application requires a next
  • Step S350 depicts a checking of whether the API required by the application uniquely belongs to a pre-defined API group of the security level. If the API uniquely belongs to a pre-defined API group, in other words, if the API uniquely belongs to a pre-defined security restriction, then the process proceeds to flow chart of Part A in Fig. 4, which will be depicted later.
  • the API does not uniquely belong to any one of the pre-defined API groups, in other words, the API uniquely belongs to an overlap of multiple sandboxes, fox example, the
  • step S390 the application will only use this API in the overlap of sandbox C and sandbox D.
  • the application has already been assigned to a security level, and the application had requested an API that is common to two or more security restrictions of the security level (e.g. API 7 in FIG 2), the application will not have been assigned to either one of the security restrictions (e.g. sandbox C and sandbox D in FIG 2), but further accessing another API that is in one of the specific security restrictions(e.g. API 4 in FIG 2) will cause the application to be assigned to that security restriction (i.e. sandbox D in FIG 2).
  • the security restrictions e.g. sandbox C and sandbox D in FIG 2
  • step S390 the process proceeds to step S395 to detect whether the application requires the next API.
  • step of S395 It is determined at step of S395 that if the application requires next API or not. If yes, the process returns to step S330 to consider the next API, or, the process is ended.
  • FIG. 4 a flow chart of Part A in Fig. 3 according to one embodiment of the present invention.
  • step S410 depicts the application manager allocating the application to the specific security restriction that includes the API requested. For example, referring to FIG. 2, if the application requires the API 2, which only belongs to the sandbox C, then the application manager allocates the application to sandbox C, that means from now on the application can only access API 1, API 2 and API 6 and API 7.
  • step S420 depicts the API execution by the application.
  • step S430 depicts the determination of the application requires next API or not, if no, then the process is ended.
  • step S440 the application manager checks if the API belongs to the specific security restriction, for example, a sandbox in Java that the application has been allocated to.
  • step S420 depicts the API execution by the application. If the API does not belong to the sandbox that the application has been allocated to, the process proceeds to step S450, the application manager blocks the API execution. Finally, the process goes back to the step S430, which depicts the determination of the application requires next API or not, if no, then the process is ended.

Abstract

The present invention discloses method and apparatus for assigning an application to a security restriction. The method for assigning an application to a security restriction, comprising the steps of: obtaining the information of an API required by the application; checking an attribute of the API; allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions. The present invention allows non- authenticated application to provide more useful consumer features implemented by using a well-defined subset of available APIs. By allowing the application to choose the API class to use, the user has more freedom than if the device only allowed the minimum set of 'safe' APIs.

Description

METHOD AND APPARATUS FOR ASSIGNING AN APPLICATION TO A SECURITY RESTRICTION
FIELD OF THE INVENTION
The present invention relates generally to information security, and more particularly to method and apparatus for assigning an application to a security restriction.
BACKGROUND OF THE INVENTION
There is a trend to make Consumer Electronic devices programmable and allow downloading of new applications to the devices. For example, mobile phones can download games, Set Top Boxes that support MHP (Multimedia Home Platform) can run applications from the broadcast, and future Blu-ray Disc players may support applications from the Blu-ray Disc. In each of these examples the device supports a JVM (Java Virtual Machine), and Java applications are executed on the device.
Java programming language is an increasing popular software programming language because Java is independent from the underlying computing platform (processor and Operating System). The source code of a Java program is compiled to byte code, which cannot be run by itself. The byte code must be converted into machine code at runtime.
A JVM interprets the byte code to machine code that is compatible with the underlying computing platform. The underlying computing platform, peripheral devices, and the software and data available to underlying computing platform are referred as resources. A software application being executed on the computing platform can request to use the resources.
Extending the concept of open programmable platforms to CE products (e.g. PVR, e-
Hub, home networks) offers a great opportunity to leverage the third party developers other than the CE product manufacturers to enhance the products, for instance, MHP offers an open middleware system allowing the third party to develop their applications to wide audience. But, it also creates the threat of malicious damage of the MHP device or unauthorized use of user private information by an untrusted application.
Since Java is used as the development platform in MHP, the security feature like sandbox, which can limit access to system resources can also be used in MHP application. The sandbox creates an environment in which there are strict limitations on what system resources the applet can request or access. Sandboxes are used when executable code comes from unknown or untrusted sources and allow the user to run untrusted code safely.
The Java sandbox has been successful in establishing a level of trust in network computing, but it has also put narrow limits on what may be done for users with applets. Unsigned applications that are untrusted by the device have only the basic set of rights, signed applications that are untrusted by the device also only have this basic set by default. An application broadcaster can request additional permission to access specific resources by providing a signed "Permission Request File" along with the application, but it is no guarantee that the application will get the permissions. Normally, it is difficult for an end- user to explicitly grant an application these permissions.
In view of the foregoing, there is a need to achieve a better balance between the availability of system resources and the system security.
OBJECT AND SUMMARY OF THE INVENTION
It is desirable to provide a method and an apparatus for assigning an application to one of the multiple security restrictions, so that a non- authenticated application can provide useful user features implemented by using a well-defined subset of available APIs (Application Programming Interface). According to an embodiment of the present invention, a method for assigning an application to a security restriction, comprising the step of: obtaining the information of an API required by the application; checking an attribute of the API; allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions. According to an embodiment of the present invention, an apparatus for assigning a security restriction to an application, comprising: obtaining means for obtaining the information of an API required by the application; checking means for checking an attribute of the API; allocating means for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
According to an embodiment of the present invention, a computer program product for assigning a security restriction to an application, comprising: code for obtaining the information of an API required by the application; code for checking an attribute of the API; code for allocating the application to a security restriction when the attribute of the
API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
According to the embodiment of the present invention, a non- authenticated application can provide more useful user features implemented by using a well-defined subset of available APIs. By allowing the application to choose the API class to use, the user has more freedom than if the device only allowed the minimum set of 'safe' APIs.
An overall understanding to the objects and effectiveness of the present invention will become apparent from the following description and claims with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 depicts a schematic diagram of a MHP basic architecture according to one embodiment of the present invention; FIG. 2 depicts a schematic structural diagram of multiple sandboxes according to one embodiment of the present invention;
FIG. 3 depicts a flow chart of assigning a downloaded application to one of multiple sandboxes according to one embodiment of the present invention;
FIG. 4 depicts a flow chart of Part A in Fig. 3 according to one embodiment of the present invention; In all of the above accompanying drawings, the same referential numerals are used to indicate the same, similar, or corresponding characteristics or functions.
DETAILED DESCRIPTION OF THE INVENTION
Referring to FIG. 1, a schematic diagram of a MHP basic architecture according to one embodiment of the present invention.
The architecture of the MHP is defined in terms of three layers: resources 40, system software 30 and application(s) 10. The application(s) 10 implements interactive services as software running in the MHP based device. As a MHP based device, a HDD (High Density Disk) based Personal video Recorder (PVR) with Internet connectivity can be used to store broadcast content, user generated content and applications downloaded from Internet as well.
The API(s) 20 lies between the application(s) 10 and the system software 30. The API 20 provides corresponding services to the application(s) 10, and the application(s) 10 accesses resources 40 only through the API(s) 20.
The resources 40 include hardware resources (for example, MPEG decoder, I/O device, CPU etc.) and software resource (for example, driver program etc.), which are representatives of hardware entities in the MHP platform. The system software 30 brings an abstract view of the resources 40, and this middle layer isolates the application 10 and the resources 40, enabling portability of the application 10. For example, an Operating System (OS) can be as system software 30, Operating System may include Windows, Mac OS or Linux etc.
The Operating System may include a Java-enabled browser that allows Operating System to retrieve and display information and to run Java applet. Also, the system may include a Java Virtual Machine (JVM) to allow Operating System to execute a Java application.
According to the embodiment of the present invention, the system software 30 includes an application manager 31, which is part of the system software 30. It interacts with all applications 10. The application manager 31 can be as a filter between downloaded code and the system software 30.
According to the embodiment of the present invention, the application manager 31 includes an obtaining unit 312, a checking unit 314 and an allocating unit 316. The obtaining unit 312 obtains the information of an API required by an application, and checking unit 314 checks the attribute of the API, for example, whether the API belongs to a security level, whether the API uniquely belongs to a security restriction, whether the API belongs to an overlap of two or more security restrictions, and whether the API belongs to an assigned security restriction of the application 10. The allocating unit 314 allocates the application to a security restriction when the attribute of the API 20 indicates the API 20 only belongs to the security restriction.
According to the embodiment of the present invention, the application manager 31 could further includes a determining unit 310 for determining the security level of the application(s) 10. The application manager 31 could further include a blocking unit 318. When the attribute of the API 20 indicates the API 20 belongs to none of the security restriction(s) of the corresponding security level before a specific security restriction is assigned to the application, or the attribute of the API 20 indicate the API 20 does not belong to the specific security restriction which has already been assigned to the application 10, the blocking unit 318 blocks this part of the application corresponding to the API from running.
It is understandable that there could be only one security level with two or more security restrictions, and under this situation there is no need to determine the security level of the application. Otherwise, determining unit 310 may send its determination of security level to the checking unit 314 and/or the allocating unit 316. It is also understandable that the allocating unit 316 may send its allocation result to the checking unit 314.
It is also understandable that the security restriction may be a sandbox in a JVM, and the security restriction could also be any similar function in ActiveX or Netscape login.
It is also understandable that the desire of this invention can also be implemented by means of a suitably programmed computer provided with a computer program for assigning an application to a security restriction. The computer program product for assigning an application to a security restriction, comprises code for obtaining the information of an API required by the application, code for checking an attribute of the API, and code for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
Such a computer program product may be stored in a storage carrier, or may be available for downloading.
Referring to FIG. 2, a schematic structural diagram of multiple sandboxes of a CE device according to one embodiment of the present invention.
The architecture of the sandboxes are defined in terms of three security levels: low level, medium level and high level. When an application is loaded to a device, the device must determine which security level the application belongs to. A number of methods can be considered to implement this determination.
One way to implement the determination is that the application is tagged with the security level so before running the application the device knows its corresponding security level, for example, the tag of the application indicates the source of the application, if the application is from the manufacturer of the CE device, its corresponding security level is high, and if the application is from the allies of the manufacturer or certain companies, its corresponding security level is middle, and if the application source is unknown, its corresponding security level is low.
The other way to implement the determination is that the application calls an API to indicate which security level it belongs to; or the device detects the security level from the APIs which have been used by the application.
It may take some time to uniquely determine the security level of the application because some security levels are supersets of others. Once the application uses an API uniquely from a security level it will not be allowed to access any APIs outside this security level. Each sandbox consists of a set of APIs that applications running in the sandbox can use. The sandboxes are (overlapping) API classes. The APIs are grouped according to a predetermined rule so that a grouping of APIs represents a "safe" combination of APIs.
Within a security level there may be multiple sandboxes. An application will be assigned to a sandbox when it accesses an API that is unique specific to that sandbox. This can be done dynamically, the application does not need to indicate which sandbox, it will be assigned to the sandbox when it accesses a restricted function associated with an API.
Sandbox A includes API 1 and API 2, sandbox B includes API 3 and API 4. Sandbox C is a superset of Sandbox A, Sandbox D is a superset of Sandbox B and contains some overlap (API 7) with sandbox C. Sandbox E is the complete set of APIs. In practice there will probably be a set of APIs that are accessible to all sandboxes.
To prevent user's private information leaking from one sandbox to another, the information used/created by an application within one sandbox will not be available to the same application within another sandbox. For example, files written by an application is tagged with the sandbox the application was running in. If the same application runs again in a different sandbox (at the same authentication level), it will not be able to read the files previously written.
Different sandboxes may be linked to different levels of authentication, some sandboxes require no authentication, some require authentication by a trusted source, and a special sandbox consisting of all APIs is only available to applications authenticated as being from the device manufacturer. For example, if an application gets a middle level of authentication from the device manufacturer, when the application requires the API2, the application will be assigned to the sandbox C, but not the sandbox A or the sandbox E. That means the accessing any APIs outside the sandbox C is prevented, the application can only access API 1, API 2, API 6 and API 7 within the sandbox C.
The authentication can be done as in MHP using public/private keys set by the device manufacturer. The device includes the public key of the trusted source and can check that the application was signed with the corresponding private key. The device will contain at least the public key of the device manufacturer to authenticate the application from the device manufacturer, which will have access to all APIs. According to one embodiment of the present invention, the APIs are grouped according to a pre-determined rule so that a grouping of APIs represents a safe combination of APIs. For instance, the manufacturer can create several pre-defined groups of APIs as different security restrictions on a MHP device, when an new application loaded to the MHP device, the device would determine security level of the application and detect which API the application require to address. If the device detects that the API required by the application uniquely belongs to one of the several pre-defined group of APIs, the device would assign the related security restriction to the application.
According to another embodiment of the present invention, whether an application can access an API depends, not only on its security level, but also on what other APIs it has used instead of what APIs it will use. In other words, the APIs are not explicitly grouped, the manufacturer only creates several rules for not grouping conflicting APIs into one security restriction on a MHP device, for instance, a rule depicts that API 1 and API 3 can not be grouped into one security restriction so if an application uses API 1 then it can no longer use API 3 and vice versa.
According to still another embodiment of the present invention, as long as the application uses APIs common to the two sandboxes, For example, an application uses APIs which common to both sandbox C and sandbox D, then it is not restricted to either one. This situation will be further depicted from following description by taking the cases of four applications: EPG (Electronic Programme Guide), Content Browser, Photo- sharing application and Interactive Game. In this example, all Internet access APIs are specific to sandbox C, all local storage APIs are specific to sandbox D, and all other APIs are in the overlap between Sandbox C and sandbox D e.g. access to user commands from the remote control, graphics libraries to draw graphics on the screen. EPG gets Electronic Programme Guide information from the Internet and presents it to the user and based on the user interaction can request some content to be recorded. EPG may first access some APIs in the overlap of the sandbox C and sandbox D to display graphics on the screen or to get user input via the remote control or to access the user's public profile. However, the first time that the application accesses an API related to Internet Access (which is specific to sandbox C), the application will be assigned to sandbox C. From that time on it can access the APIs that are specific to sandbox C and any APIs in the overlap with sandbox D. Content application, this application lets the user browse and navigate through content on the disc (e.g. photos), may first access some APIs in the overlap of the two Sandboxes e.g. to display graphics on the screen or get user input via the remote control or to access the user's public profile. However, the first time that the Application accesses an API related to Local Storage (which is specific to sandbox D), the application will be assigned to sandbox D. From that time on it can access only the APIs that are specific to sandbox D and any APIs in the overlap with sandbox C. The files in local storage are tagged with the sandbox the application was running in so if the same application later runs in a different sandbox it cannot read information from the other sandbox. Photo-sharing application, this application allows the user to share photos from their local storage through the Internet, may first access some APIs in the overlap of the two Sandboxes e.g. to display graphics on the screen or get user input via the remote control or to access the user's public profile. If the application then accesses a Local Storage API then it will be assigned to Sandbox D. Later when the application tries to access an Internet Access API, it will be blocked (by the Application Manager) as these APIs are outside of
Sandbox D. Similarly, if the application first accesses an Internet Access API then it will be assigned to Sandbox C. Later if it tries to access a Local Storage API then it will be blocked (by the Application Manager) because those APIs are outside of Sandbox C. To be able to use both the Internet Access APIs and the Local Storage APIs is not possible for an application with this level of authentication. It may be possible if the application has a higher level of authentication (e.g. from the device manufacturer).
The Interactive Game Application does not need to access the local storage or the Internet. This application will access APIs to display graphics on the screen and take remote control commands from the user. This application will only use APIs in the overlap between Sandbox C and Sandbox D and will never be assigned to either, however this is no security problem in this case - the application can only perform actions that an application assigned to Sandbox C could do or an application assigned to Sandbox D could do, it can never do things that an application in Sandbox C or Sandbox D could not do.
According to the embodiment of the present invention, the application manager may restrict access to an API because the application has used an API from another sandbox, thus the choice of whether an application can access an API is dynamic. It is understandable that there could be only one security level with two or more security restriction(s) (overlapped or not).
Referring to FIG. 3, a flow chart of assigning a downloaded application to one of multiple sandboxes according to one embodiment of the present invention.
The process begins with step S310, which depicts an user accessing the Internet with a Java enabled browser or other application, Security for the JVM associated with the browser is determined initially by browser policies that were programmed into the browser by the manufacturer. The process proceeds to step S320, which depicts downloading a Java application.
The process proceeds to step S325, which depicts determination of the security level of the application based on the authentication of the application, for example, middle level. Once the application manager determines the security level of the application it will prevent the application from accessing any API not included in this security level. The excluded APIs will appear to the application either not implement or always return an error.
Alternatively, the device can terminate an application that violates the security level.
The process proceeds to step S330, the application manager obtains the information of the API required by the application.
Step S340 depicts the application manager checking if the API is inconsistent with the applications current security level. If the application has already been assigned to a security level and if the requested API is within this security level, for example, the API belongs to a security restriction of this security level, then it is consistent, otherwise it is inconsistent.
If the API is inconsistent with the security level then the process proceeds to step S370, which depicts the application manager blocking the applications access to this API. The process is then proceeded to step S395 to detect whether the application requires a next
API. Alternatively the application manager could terminate the application in this case.
If the API is consistent with the applications security level then the process proceeds to Step S350, which depicts a checking of whether the API required by the application uniquely belongs to a pre-defined API group of the security level. If the API uniquely belongs to a pre-defined API group, in other words, if the API uniquely belongs to a pre-defined security restriction, then the process proceeds to flow chart of Part A in Fig. 4, which will be depicted later.
If the API does not uniquely belong to any one of the pre-defined API groups, in other words, the API uniquely belongs to an overlap of multiple sandboxes, fox example, the
API uniquely belongs to the overlap of sandbox C and sandbox D as shown in Fig. 2, then the process proceeds to step S390, the application will only use this API in the overlap of sandbox C and sandbox D.
In many cases the application has already been assigned to a security level, and the application had requested an API that is common to two or more security restrictions of the security level (e.g. API 7 in FIG 2), the application will not have been assigned to either one of the security restrictions (e.g. sandbox C and sandbox D in FIG 2), but further accessing another API that is in one of the specific security restrictions(e.g. API 4 in FIG 2) will cause the application to be assigned to that security restriction (i.e. sandbox D in FIG 2).
After step S390, the process proceeds to step S395 to detect whether the application requires the next API.
It is determined at step of S395 that if the application requires next API or not. If yes, the process returns to step S330 to consider the next API, or, the process is ended.
Referring to FIG. 4, a flow chart of Part A in Fig. 3 according to one embodiment of the present invention.
If the API uniquely belongs to a pre-defined API group, in other words, if the API uniquely belongs to a pre-defined security restriction, then the process proceeds to step S410, which depicts the application manager allocating the application to the specific security restriction that includes the API requested. For example, referring to FIG. 2, if the application requires the API 2, which only belongs to the sandbox C, then the application manager allocates the application to sandbox C, that means from now on the application can only access API 1, API 2 and API 6 and API 7. The process proceeds to step S420, which depicts the API execution by the application. The process proceeds to step S430, which depicts the determination of the application requires next API or not, if no, then the process is ended.
If the application requires a next API, then the process proceeds to step S440, the application manager checks if the API belongs to the specific security restriction, for example, a sandbox in Java that the application has been allocated to.
If the API belongs to the sandbox that the application has been allocated to, then the process proceeds to step S420, which depicts the API execution by the application. If the API does not belong to the sandbox that the application has been allocated to, the process proceeds to step S450, the application manager blocks the API execution. Finally, the process goes back to the step S430, which depicts the determination of the application requires next API or not, if no, then the process is ended.
It should be noted that the above-mentioned embodiment illustrate rather than limit the invention and that those skilled in the art will be able to design alternative embodiment without departing from the scope of the appended claims. In the claims, the word
'comprising' does not exclude the presence of elements or steps not listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several district elements and by means of a suitable programmed computer. In the means claims enumerating several means, several of these means can be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicated any ordering. These words are to be interpreted as names.

Claims

CLAIMS:
1. A method for assigning an application to a security restriction, comprising the step of:
(a) obtaining the information of an API required by the application;
(b) checking an attribute of the API;
(c) allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
2. The method according to claim 1, wherein there are at least two security levels respectively associated with at least one of the pre-determined security restrictions, further comprising the step of: determining a security level of the application.
3. The method according to claim 2, wherein when the attribute of the API indicates the API belongs to none of the security restriction(s) corresponding to the security level, further comprising the step of: blocking the application from accessing the API.
4. The method according to claim 1, further comprising the step of: detecting if the application requires a next API.
5. The method according to claim 4, further comprising the step of: checking if the next API belongs to the security restriction; blocking the application from accessing the next API when the next API does not belong to the security restriction.
6. The method according to claim 1, wherein the security restriction is a sandbox in Java.
7. An apparatus for assigning a security restriction to an application, comprising: obtaining means for obtaining the information of an API required by the application; checking means for checking an attribute of the API; allocating means for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
8. The apparatus according to claim 7, wherein there are at least two security levels respectively associated with at least one of the pre-determined security restrictions, further comprising determining means for determining a security level of the application.
9. The apparatus according to claim 8, wherein when the attribute of the API indicates the API belongs to none of the security restriction(s) corresponding to the security level, further comprising means for blocking the application from accessing the API.
10. The apparatus according to claim 7, wherein obtaining means obtains another API required by the application, checking means checks an attribute of the anther API, blocking means blocks the application from accessing the another API when the attribute of the another API indicates the another API does not belong to the security restriction.
11. A computer program product for assigning a security restriction to an application, comprising: code for obtaining the information of an API required by the application; code for checking an attribute of the API; code for allocating the application to a security restriction when the attribute of the API indicates the API only belongs to the security restriction, wherein the security restriction is one of a plurality of pre-determined security restrictions.
PCT/IB2007/050934 2006-03-30 2007-03-19 Method and apparatus for assigning an application to a security restriction WO2007113709A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610068399.2 2006-03-30
CN200610068399 2006-03-30

Publications (1)

Publication Number Publication Date
WO2007113709A1 true WO2007113709A1 (en) 2007-10-11

Family

ID=38357687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2007/050934 WO2007113709A1 (en) 2006-03-30 2007-03-19 Method and apparatus for assigning an application to a security restriction

Country Status (1)

Country Link
WO (1) WO2007113709A1 (en)

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012142943A1 (en) * 2011-04-21 2012-10-26 北京奇虎科技有限公司 Method and device for defense by using sandbox, and secure browser
US8799994B2 (en) 2011-10-11 2014-08-05 Citrix Systems, Inc. Policy-based application management
US8806570B2 (en) 2011-10-11 2014-08-12 Citrix Systems, Inc. Policy-based application management
US8813179B1 (en) 2013-03-29 2014-08-19 Citrix Systems, Inc. Providing mobile device management functionalities
US8850049B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing mobile device management functionalities for a managed browser
US8849978B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing an enterprise application store
US8850010B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing a managed browser
US8869235B2 (en) 2011-10-11 2014-10-21 Citrix Systems, Inc. Secure mobile browser for protecting enterprise data
US8887230B2 (en) 2012-10-15 2014-11-11 Citrix Systems, Inc. Configuring and providing profiles that manage execution of mobile applications
US8910239B2 (en) 2012-10-15 2014-12-09 Citrix Systems, Inc. Providing virtualized private network tunnels
US8910264B2 (en) 2013-03-29 2014-12-09 Citrix Systems, Inc. Providing mobile device management functionalities
US8914845B2 (en) 2012-10-15 2014-12-16 Citrix Systems, Inc. Providing virtualized private network tunnels
US8959579B2 (en) 2012-10-16 2015-02-17 Citrix Systems, Inc. Controlling mobile device access to secure data
US9053340B2 (en) 2012-10-12 2015-06-09 Citrix Systems, Inc. Enterprise application store for an orchestration framework for connected devices
US9111105B2 (en) 2011-10-11 2015-08-18 Citrix Systems, Inc. Policy-based application management
US9215225B2 (en) 2013-03-29 2015-12-15 Citrix Systems, Inc. Mobile device locking with context
US9280377B2 (en) 2013-03-29 2016-03-08 Citrix Systems, Inc. Application with multiple operation modes
US9516022B2 (en) 2012-10-14 2016-12-06 Getgo, Inc. Automated meeting room
WO2016206565A1 (en) * 2015-06-26 2016-12-29 阿里巴巴集团控股有限公司 Malicious program detection method and device
US9563488B2 (en) 2014-05-29 2017-02-07 Apple Inc. Sharing extension points to allow an application to share content via a sharing extension
US9606774B2 (en) 2012-10-16 2017-03-28 Citrix Systems, Inc. Wrapping an application with field-programmable business logic
US9971585B2 (en) 2012-10-16 2018-05-15 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US9985850B2 (en) 2013-03-29 2018-05-29 Citrix Systems, Inc. Providing mobile device management functionalities
US10242159B2 (en) 2010-01-22 2019-03-26 Deka Products Limited Partnership System and apparatus for electronic patient care
US10284627B2 (en) 2013-03-29 2019-05-07 Citrix Systems, Inc. Data management for an application with multiple operation modes
US10453157B2 (en) 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
WO2020134311A1 (en) * 2018-12-26 2020-07-02 中兴通讯股份有限公司 Method and device for detecting malware
US10872685B2 (en) 2010-01-22 2020-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US10908896B2 (en) 2012-10-16 2021-02-02 Citrix Systems, Inc. Application wrapping for application management framework
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11244745B2 (en) 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999030217A1 (en) * 1997-12-11 1999-06-17 Sun Microsystems, Inc. Protection domains to provide security in a computer system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999030217A1 (en) * 1997-12-11 1999-06-17 Sun Microsystems, Inc. Protection domains to provide security in a computer system

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
GONG L ET AL: "Going beyond the sandbox: an overview of the new security architecture in the Java<TM> Development Kit 1.2", PROCEEDINGS OF THE USENIX SYMPOSIUM ON INTERNET TECHNOLOGIES AND SYSTEMS, XX, XX, 8 December 1997 (1997-12-08), pages 103 - 112, XP002100907 *
HAWBLITZEL C ET AL: "IMPLEMENTING MULTIPLE PROTECTION DOMAINS IN JAVA", PROCEEDINGS OF THE USENIX ANNUAL TECHNICAL CONFERENCE, XX, XX, 15 June 1998 (1998-06-15), pages 259 - 270, XP008050745 *
JENSEN T ET AL: "VERIFICATION OF CONTROL FLOW BASED SECURITY PROPERTIES", PROCEEDINGS OF THE 1999 IEEE SYMPOSIUM ON SECURITY AND PRIVACY. OAKLAND, CA, MAY 9 - 12, 1999, PROCEEDINGS OF THE IEEE SYMPOSIUM ON SECURITY AND PRIVACY, LOS ALAMITOS, CA : IEEE COMP. SOC, US, 9 May 1999 (1999-05-09), pages 89 - 103, XP000871975, ISBN: 0-7695-0177-X *
SANDHU R S ET AL: "ACCESS CONTROL: PRINCIPLES AND PRACTICE", IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER,NEW YORK, NY, US, vol. 32, no. 9, 1 September 1994 (1994-09-01), pages 40 - 48, XP000476554, ISSN: 0163-6804 *
WALLACH D S ET AL: "EXTENSIBLE SECURITY ARCHITECTURES FOR JAVA", OPERATING SYSTEMS REVIEW, ACM, NEW YORK, NY, US, vol. 31, no. 5, December 1997 (1997-12-01), pages 116 - 128, XP000771026, ISSN: 0163-5980 *

Cited By (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US10242159B2 (en) 2010-01-22 2019-03-26 Deka Products Limited Partnership System and apparatus for electronic patient care
US10453157B2 (en) 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11810653B2 (en) 2010-01-22 2023-11-07 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US11776671B2 (en) 2010-01-22 2023-10-03 Deka Products Limited Partnership Electronic patient monitoring system
US11524107B2 (en) 2010-01-22 2022-12-13 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11424029B2 (en) 2010-01-22 2022-08-23 Deka Products Limited Partnership System, method and apparatus for electronic patient care
US11244745B2 (en) 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US10872685B2 (en) 2010-01-22 2020-12-22 Deka Products Limited Partnership Electronic patient monitoring system
WO2012142943A1 (en) * 2011-04-21 2012-10-26 北京奇虎科技有限公司 Method and device for defense by using sandbox, and secure browser
US9111105B2 (en) 2011-10-11 2015-08-18 Citrix Systems, Inc. Policy-based application management
US9143529B2 (en) 2011-10-11 2015-09-22 Citrix Systems, Inc. Modifying pre-existing mobile applications to implement enterprise security policies
US8881229B2 (en) 2011-10-11 2014-11-04 Citrix Systems, Inc. Policy-based application management
US11134104B2 (en) 2011-10-11 2021-09-28 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US8886925B2 (en) 2011-10-11 2014-11-11 Citrix Systems, Inc. Protecting enterprise data through policy-based encryption of message attachments
US9286471B2 (en) 2011-10-11 2016-03-15 Citrix Systems, Inc. Rules based detection and correction of problems on mobile devices of enterprise users
US8799994B2 (en) 2011-10-11 2014-08-05 Citrix Systems, Inc. Policy-based application management
US10469534B2 (en) 2011-10-11 2019-11-05 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US9213850B2 (en) 2011-10-11 2015-12-15 Citrix Systems, Inc. Policy-based application management
US10402546B1 (en) 2011-10-11 2019-09-03 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US8806570B2 (en) 2011-10-11 2014-08-12 Citrix Systems, Inc. Policy-based application management
US10063595B1 (en) 2011-10-11 2018-08-28 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US10044757B2 (en) 2011-10-11 2018-08-07 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US9183380B2 (en) 2011-10-11 2015-11-10 Citrix Systems, Inc. Secure execution of enterprise applications on mobile devices
US9043480B2 (en) 2011-10-11 2015-05-26 Citrix Systems, Inc. Policy-based application management
US9521147B2 (en) 2011-10-11 2016-12-13 Citrix Systems, Inc. Policy based application management
US9529996B2 (en) 2011-10-11 2016-12-27 Citrix Systems, Inc. Controlling mobile device access to enterprise resources
US9143530B2 (en) 2011-10-11 2015-09-22 Citrix Systems, Inc. Secure container for protecting enterprise data on a mobile device
US9137262B2 (en) 2011-10-11 2015-09-15 Citrix Systems, Inc. Providing secure mobile device access to enterprise resources using application tunnels
US8869235B2 (en) 2011-10-11 2014-10-21 Citrix Systems, Inc. Secure mobile browser for protecting enterprise data
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9386120B2 (en) 2012-10-12 2016-07-05 Citrix Systems, Inc. Single sign-on access in an orchestration framework for connected devices
US9053340B2 (en) 2012-10-12 2015-06-09 Citrix Systems, Inc. Enterprise application store for an orchestration framework for connected devices
US9854063B2 (en) 2012-10-12 2017-12-26 Citrix Systems, Inc. Enterprise application store for an orchestration framework for connected devices
US9189645B2 (en) 2012-10-12 2015-11-17 Citrix Systems, Inc. Sharing content across applications and devices having multiple operation modes in an orchestration framework for connected devices
US9516022B2 (en) 2012-10-14 2016-12-06 Getgo, Inc. Automated meeting room
US9467474B2 (en) 2012-10-15 2016-10-11 Citrix Systems, Inc. Conjuring and providing profiles that manage execution of mobile applications
US9654508B2 (en) 2012-10-15 2017-05-16 Citrix Systems, Inc. Configuring and providing profiles that manage execution of mobile applications
US8887230B2 (en) 2012-10-15 2014-11-11 Citrix Systems, Inc. Configuring and providing profiles that manage execution of mobile applications
US8904477B2 (en) 2012-10-15 2014-12-02 Citrix Systems, Inc. Configuring and providing profiles that manage execution of mobile applications
US8910239B2 (en) 2012-10-15 2014-12-09 Citrix Systems, Inc. Providing virtualized private network tunnels
US8914845B2 (en) 2012-10-15 2014-12-16 Citrix Systems, Inc. Providing virtualized private network tunnels
US8931078B2 (en) 2012-10-15 2015-01-06 Citrix Systems, Inc. Providing virtualized private network tunnels
US9521117B2 (en) 2012-10-15 2016-12-13 Citrix Systems, Inc. Providing virtualized private network tunnels
US9973489B2 (en) 2012-10-15 2018-05-15 Citrix Systems, Inc. Providing virtualized private network tunnels
US10908896B2 (en) 2012-10-16 2021-02-02 Citrix Systems, Inc. Application wrapping for application management framework
US9858428B2 (en) 2012-10-16 2018-01-02 Citrix Systems, Inc. Controlling mobile device access to secure data
US10545748B2 (en) 2012-10-16 2020-01-28 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US9602474B2 (en) 2012-10-16 2017-03-21 Citrix Systems, Inc. Controlling mobile device access to secure data
US9606774B2 (en) 2012-10-16 2017-03-28 Citrix Systems, Inc. Wrapping an application with field-programmable business logic
US8959579B2 (en) 2012-10-16 2015-02-17 Citrix Systems, Inc. Controlling mobile device access to secure data
US9971585B2 (en) 2012-10-16 2018-05-15 Citrix Systems, Inc. Wrapping unmanaged applications on a mobile device
US9413736B2 (en) 2013-03-29 2016-08-09 Citrix Systems, Inc. Providing an enterprise application store
US8881228B2 (en) 2013-03-29 2014-11-04 Citrix Systems, Inc. Providing a managed browser
US8813179B1 (en) 2013-03-29 2014-08-19 Citrix Systems, Inc. Providing mobile device management functionalities
US9948657B2 (en) 2013-03-29 2018-04-17 Citrix Systems, Inc. Providing an enterprise application store
US9158895B2 (en) 2013-03-29 2015-10-13 Citrix Systems, Inc. Providing a managed browser
US8850049B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing mobile device management functionalities for a managed browser
US9985850B2 (en) 2013-03-29 2018-05-29 Citrix Systems, Inc. Providing mobile device management functionalities
US9112853B2 (en) 2013-03-29 2015-08-18 Citrix Systems, Inc. Providing a managed browser
US9215225B2 (en) 2013-03-29 2015-12-15 Citrix Systems, Inc. Mobile device locking with context
US10097584B2 (en) 2013-03-29 2018-10-09 Citrix Systems, Inc. Providing a managed browser
US9280377B2 (en) 2013-03-29 2016-03-08 Citrix Systems, Inc. Application with multiple operation modes
US10284627B2 (en) 2013-03-29 2019-05-07 Citrix Systems, Inc. Data management for an application with multiple operation modes
US8910264B2 (en) 2013-03-29 2014-12-09 Citrix Systems, Inc. Providing mobile device management functionalities
US9455886B2 (en) 2013-03-29 2016-09-27 Citrix Systems, Inc. Providing mobile device management functionalities
US8849978B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing an enterprise application store
US10476885B2 (en) 2013-03-29 2019-11-12 Citrix Systems, Inc. Application with multiple operation modes
US8849979B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing mobile device management functionalities
US8850010B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing a managed browser
US10701082B2 (en) 2013-03-29 2020-06-30 Citrix Systems, Inc. Application with multiple operation modes
US8850050B1 (en) 2013-03-29 2014-09-30 Citrix Systems, Inc. Providing a managed browser
US8898732B2 (en) 2013-03-29 2014-11-25 Citrix Systems, Inc. Providing a managed browser
US9369449B2 (en) 2013-03-29 2016-06-14 Citrix Systems, Inc. Providing an enterprise application store
US8893221B2 (en) 2013-03-29 2014-11-18 Citrix Systems, Inc. Providing a managed browser
US10965734B2 (en) 2013-03-29 2021-03-30 Citrix Systems, Inc. Data management for an application with multiple operation modes
US9355223B2 (en) 2013-03-29 2016-05-31 Citrix Systems, Inc. Providing a managed browser
US8996709B2 (en) 2013-03-29 2015-03-31 Citrix Systems, Inc. Providing a managed browser
WO2014158228A1 (en) * 2013-03-29 2014-10-02 Citrix Systems, Inc. Providing a managed browser
US11379273B2 (en) 2014-05-29 2022-07-05 Apple Inc. Sharing extension points to allow an application to share content via a sharing extension
US9563488B2 (en) 2014-05-29 2017-02-07 Apple Inc. Sharing extension points to allow an application to share content via a sharing extension
US10503564B2 (en) 2014-05-29 2019-12-10 Apple Inc. Method and apparatus for handling security of an application and its extension
US9684547B2 (en) 2014-05-29 2017-06-20 Apple Inc. Method and apparatus for handling security of an application and its extension
US9811393B2 (en) 2014-05-29 2017-11-07 Apple Inc. Consistent extension points to allow an extension to extend functionality of an application to another application
WO2016206565A1 (en) * 2015-06-26 2016-12-29 阿里巴巴集团控股有限公司 Malicious program detection method and device
WO2020134311A1 (en) * 2018-12-26 2020-07-02 中兴通讯股份有限公司 Method and device for detecting malware

Similar Documents

Publication Publication Date Title
WO2007113709A1 (en) Method and apparatus for assigning an application to a security restriction
US10831886B2 (en) Virtual machine manager facilitated selective code integrity enforcement
KR101456489B1 (en) Method and apparatus for managing access privileges in a CLDC OSGi environment
US7673109B2 (en) Restricting type access to high-trust components
US7565641B2 (en) Securely providing extensible third-party plug-ins
KR101238572B1 (en) Automatic update of computer-readable components to support a trusted environment
US9684785B2 (en) Providing multiple isolated execution environments for securely accessing untrusted content
US6345361B1 (en) Directional set operations for permission based security in a computer system
KR101970744B1 (en) Trust level activation
RU2637878C2 (en) Authentication of processes and resource permission
US20070033420A1 (en) Automatic update of computer-readable components to support a trusted environment
CN109960597B (en) Dynamic registration method and related device of application layer interface
US10795974B2 (en) Memory assignment for guest operating systems
US8938473B2 (en) Secure windowing for labeled containers
KR101321479B1 (en) Method and Apparatus for preventing illegal copy of application software using access control of process
JP4507569B2 (en) Information processing apparatus, information processing method, program, and recording medium
Kim et al. Self-controllable mobile app protection scheme based on binary code splitting
Chandwani Light-weight proactive approach for safe execution of untrusted code
WO2010044066A1 (en) Method and apparatus for operating a computer system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07735163

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07735163

Country of ref document: EP

Kind code of ref document: A1