Classifications

• • 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/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
• • 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
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2101—Auditing as a secondary aspect

Definitions

• the invention generally relates to access control. More particularly, but not exclusively, the invention relates to software based access control of different principals.
• Some operating systems have employed resource-based access control for mapping a trust level of an authenticated program or user to an access policy. It is also possible to require each application used to be reliably certified as authenticated. This enables restricting the access of each application only to given permitted resources. Such an access control mechanism may become problematic, however, if a user should be able to use arbitrary applications (possibly unauthenticated programs) to access some access-controlled resources that are yet critical for some specific operation.
• DRM Digital Rights Management
• the media players should be authenticated or certified.
• authenticating every media player is costly and cumbersome, due to required recertification and signing of the media player even after every minor patch or upgrade.
• the certificating can be necessary to ensure that any data managed by a program is never passed to another program, device or user.
• a method for controlling access of arbitrary computer executable applications to the resources comprising: maintaining a set of conditional access control constraints for defining permissible combinations of the resources usable in conjunction by the applications; and enabling running the applications only within the constraints of permissible combinations of resources used by the applications that are run in conjunction.
• arbitrary applications can be access controlled based on the access control constraints.
• the resources may be defined as usable in conjunction when the resources are usable simultaneously and / or in a sequence.
• the permissible combinations may be defined indirectly by defining non- permissible combinations.
• the defining of non-permissible combinations may enable excluding forbidden combination of resource use especially by non-certified applications that cannot be trusted to be designed to respect copyrights.
• the access control constraints may define at least two mutually exclusive functional blocks or at least two mutually exclusive combinations of functional blocks.
• the access control constraints may be defined by means of access control objects. Different services may be assigned with respective service identifiers, different access objects are associated with respective access logs and services call for access objects and thereby the service identifiers of calling services are respectively stored in the access logs of the called services.
• the access control constraints may be functions capable of each returning a single Boolean value based on one or more of the access logs.
• Providing access logs with service identifiers indicative of services using given access control objects and computing Boolean values as output of access control constraints may result in computationally simple access control mechanism.
• Access of the arbitrary applications to different services usable in conjunction may also be controlled by the maintained conditional access control constraints by enabling running the applications only within the constraints of permissible combinations of services used by the applications that are run in conjunction.
• a data processing terminal having various resources and capable of executing arbitrary computer executable applications using the resources, comprising: a memory for maintaining a set of conditional access control constraints defining permissible combinations of the resources usable in conjunction by the applications; and a processor configured to run the applications only within the constraints of permissible combinations of resources used by the applications that are run in conjunction.
• a computer program for controlling the operation in a data processing terminal having various resources in order to control access of arbitrary computer executable applications to the resources comprising: computer program code for causing the terminal to maintain a set of conditional access control constraints for defining permissible combinations of the resources usable in conjunction by the applications; and computer program code for causing the terminal to enable running the applications only within the constraints of permissible combinations of resources used by the applications that are run in conjunction.
• a sub-assembly for controlling the operation in a data processing terminal having various resources in order to control access of arbitrary computer executable applications to the resources, the sub-assembly comprising: means for causing the terminal to maintain a set of conditional access control constraints for defining permissible combinations of the resources usable in conjunction by the applications; and means for causing the terminal to enable running the applications only within the constraints of permissible combinations of resources used by the applications that are run in conjunction.
• the means for causing the terminal to maintain the set of conditional access control constraints and / or the means for causing the terminal to enable running the applications within the constraints of permissible combinations of resources may be based on any combination of the following: a chipset circuitry and computer code stored in one or more chipsets.
• a method of manufacturing and controlling a data processing terminal having various resources in order to control access of arbitrary computer executable applications to the resources comprising: storing in the terminal computer program code for causing the terminal to maintain a set of conditional access control constraints for defining permissible combinations of the resources usable in conjunction by the applications; and storing in the terminal computer program code for causing the terminal to enable running the applications only within the constraints of permissible combinations of resources used by the applications that are run in conjunction.
• the computer program code or software may be provided as a computer product or products carried and / or stored on a data medium or embedded in a data signal.
• the software may also be hosted by one or more devices in a distributed fashion.
• Fig. 1 shows a block diagram of a mobile station according to an embodiment of the invention
• Fig. 2 shows an illustrational system of the main components according to an embodiment of the invention
• Fig. 3 shows a flowchart representing the operation according to an embodiment of the invention.
• Fig. 1 shows a block diagram of a Mobile Station (MS) 100 according to an embodiment of the invention.
• the MS 100 includes a radio block 110, a memory 120 that includes a non- volatile memory 121 for storing long-term operating instructions 122 and a work memory 123.
• the MS 100 further includes a processor 130 and a user interlace 140. All of these parts are connected to the processor 130.
• the processor is configured to read the long-term operating instructions 122 from the non- volatile memory 121 and run desired applications and services using the work memory 123.
• the mobile station may be, for example, a smart phone capable of running operator-specific and/or user-defined applications.
• the mobile station may be capable of running software that complies with open specifications.
• the physical structure of the mobile station 100 is not however essential as long as it allows controlling the access of some different software based elements with each other.
• the access control mechanism does not prohibit the termination of any process.
• a description of a framework for the invention according to an embodiment is illustrated in Fig. 2 provided based on the notions of services 201, service identifiers 202, access control constraints 203 also referred to as sandbox constraints, sets of principals 204, access logs 205, service conduits 206 and principals 207.
• the purpose of the framework is to provide the ability to provide configurable constraints on the behaviour of communicating and non- communicating sets of programs.
• a service embraces any mechanisms in an operating system that are usable to provision use of operating system features, resources or functions to a principal or service conduit. These mechanisms include operating system calls, device drivers and/or server programs.
• a service identifier is an arbitrary unique name for any service.
• the identifier can be statically assigned or dynamically generated.
• the service identifiers can contain a structure or conform to a given hierarchy in order to provide uniqueness when dynamically generated.
• the service identifiers can be represented as arbitrary bit-vectors, for instance.
• a service identifier should reliably identify a service.
• a resource conduit, or a service conduit refers to any local service that is usable for transferring data or providing a service.
• These local services or objects can be, for example, files or programs with Inter Process Control (IPC) capability.
• IPC Inter Process Control
• OS Symbian® Operating System
• the service conduits can involve server programs.
• a service conduit, like a principal (described in the following), can be live or dead.
• a principal refers to an object of the access controlling (that is, constraining) an application or program, for instance.
• a principal may be a service conduit and a service conduit may be a principal.
• Each principal is associated with a respective access log.
• a principal is live when it exists in the system and its access log is available for inspection.
• a dead principal has already performed its function and has been removed from the system. For a dead principal, no access log is necessarily available for inspection. There is also not necessarily any information available as to what function(s) a dead principal has performed, when and / or how.
• the change of a principal from a live state to a dead state is referred to as termination of a principal.
• Access object is a collective term for covering both principals and service conduits by a common name.
• the access log is associated by attaching, for example, to every access object.
• An access log lists all the service identifiers of services that have provided service or information to the access object.
• a set of principals that can be computed explicitly consists of live principals.
• a set that consists of live principals and zero or more dead principals is referred to as a history of principals.
• a complete history of principals cannot necessarily be represented explicitly to avoid memory overflow. Instead, all information relevant to an access control constraint concerning a history of principals must be propagated from the dead principals to the live principals. This is feasible, given that the access control constraints are of a certain nature.
• An access control constraint that is, an access constraint, is evaluated over the access logs of principals in sets of principals or histories of principals.
• An access constraint is preferably a function that returns a Boolean value TRUE or FALSE.
• the access constraints are implemented using a logic formula, for example. An access control constraint for a set of principals should result the same value even if a member in a sets of principals is terminated. Otherwise, the access constraints might not be able to cope with sudden termination of a principal.
• Fig. 2 shows an illustrational system of the main components according to an embodiment of the invention.
• Fig. 2 illustrates the relationship between different elements of an access constraint system. It should be appreciated that there is a distinction between computing a flow of service provisioning over a service conduit and the flow of information over a service conduit.
• the direction of information flow is fast to compute based on the sender and receiver relationship that is either a simplex or duplex relationship.
• a service may be rendered with the help of a complex protocol exchange, involving multiple signals by both parties, initiated either by the provider or the consumer of that service. Without knowing the exact protocol syntax and semantics it is not feasible to compute which party is the consumer and which party is the producer of that service. Two ways to resolve this are suggested: the services are annotated (it is easy to determine or compute which party is the consumer and which party is the producer) or it is assumed that services are provided in both directions (i.e. both parties in an exchange are both consumers and producers).
• each service identifier there is associated a set of services that are exclusively allowed to enter the service identifier into an access log.
• access control constraints are based on computing access control constraints for the sets of principals. This computation can be performed in a multitude of ways. For instance, the access control constraints can themselves provide sufficient expressive power and information to implicitly define these sets. Alternatively, the sets of principals can be defined via explicitly in the access control constraints using a grouping formula based on e.g. propositional logic.
• the access control constraints may be expressed using first order predicate logic with a predicate P(principal, propositional logic formula over service identifiers) defined to be the value of propositional logic formula over service identifiers when evaluated over the service identifiers in the access log of principal.
• the access control constraints can be supplied in a variety of ways, for instance, by fixing the access control constraints during time of manufacture of the embodiment of this invention or by allowing on-the-fly policy updates such as so- called authenticated Over-the-Air updates of security policies.
• the access control constraints can be supplied by authenticating access control update messages using a contemporary PKI or shared secrets and sending them over the
• Such authenticating access control update may involve one or more insertions of new constraints and / or removal of old ones constraints.
• the dynamic aspect of the system affects the definition of the access control constraints. It is practically unavoidable that any principal involved in the provisioning of a service may terminate immediately after it has performed its function, or even whilst it should perform its function, either intentionally or accidentally. For example, the chain of events may be such that a first principal first writes data to a first file and terminates. A second principal is subsequently started to forward that data to a second file. This clearly implies transitivity for the service identifiers in the access logs, but also less obviously has an impact on how the sets of principals may be formed.
• An access control constraint should not prohibit the termination of a principal. Sometimes, a principal may suddenly terminate. This has implications for access control constraints evaluated over sets of principals, as the sets may contain more than one member element and any one of them may terminate.
• Each access control constraint is split into a grouping formula and an access control formula.
• the purpose of the grouping formula is to compute the sets of principals over which the access control formula must hold.
• the grouping formula is defined using propositional logic over a universe of the propositions available related to the attributes of principals. For example, if a scalar value denoting a trust level can be associated with each principal, a grouping formula can be given as a trust level threshold value such as value 42.
• a principal may have a set of static authorizations.
• a principal may also have an authenticated creator.
• a grouping formula can then be stated in the form "has authorization X" and "is NOT published by Y" or even "has trust level ⁇ 42".
• a grouping formula can also include a proposition that limits an access control constraint to a single defined principal.
• An additional access control constraint directive is singleton is defined in an embodiment of the invention. If for an access control constraint the is singleton directive is defined to be true then the grouping constraint produces sets of principals that contain exactly one principal that causes the grouping formula to evaluate to true. If the directive is singleton is false then all the principals that satisfy the grouping constraint G of the access control constraint are placed into a common set of principals. This means that if is singleton is false corresponding to a grouping constraint G then there will exist zero or one histories of principals for G at any given time. If is singleton is true for a grouping constraint G then there may be many (or none) singleton sets of (live) principals each containing exactly one principal for G alive at any moment of time.
• the reason for creating a mechanic like is singleton is to allow the use of access control formula of the form 'IF service identified by id x is NOT present in the access log for a principal THEN service identified by id_y is allowed for that principal'.
• a similar feature is implemented in an alternative embodiment of the invention by adding expressive power beyond that of normal propositional logic to the computational formula.
• the use of is singleton enables using standard propositional logic.
• the advantage of using a separate is singleton bit is also that it is simple to conclude how to recover from an attempted policy violation (i.e. attempted violation of an access control constraint).
• the access control constraint be denoted as ⁇ is_singleton, G, S> where G is the grouping formula and S is the access control formula.
• the time complexity is O(l) when adding an access control constraint, O(n) (where n is the number of access control constraints) when a principal is added and O(l) when a principal is killed.
• the access control formula can be defined using propositional logic by evaluation over a union of service identifiers in the access lists. As such, an access control formula is inherently true or false for an entire set of principals.
• a forbidden state is basically a collection of events in access logs that cannot all happen in the lifetime of a single set of principals.
• the access control constraints are advantageously part of the Trusted Computing Base (TCB) known from Symbian and can only be modified, created, added or deleted by TCB enabled programs.
• the constraints are stored under into a secure directory such as ⁇ sys ⁇ sandboxes.
• the service identifiers are typically integers for efficient processing.
• a table in ⁇ sys ⁇ sandboxes ⁇ identifiers defines a Secure Identifier (SID) and the capabilities required to set a service identifier in an access log.
• SID Secure Identifier
• Each identifier is advantageously given a human readable name for reference with the access control formula, for example.
• Microphone Denotes the use of a microphone.
• Speaker Denotes the use of a speaker.
• Networking Denotes the use of networking capabilities.
• File system Write Denotes the use of a file system for writing data.
• File system Read Denotes the use of the file system for reading data.
• DRM Denotes the reading of DRM protected data.
• Non-UI User Interface
• This service identifier is set by all system functions that are not associated with UI functions.
• the attributes available in the grouping formula are SID and the capabilities of programs.
• the attributes available in the access control formula are the capabilities and the service identifiers.
• An access log in accordance with an embodiment of the invention is simply a bit vector that has one bit for each service identifier.
• the union of two access logs can be computed simply using a bit-wise OR operation, wherein a bitwise operation is one in which each bit is treated independently of all the other bits.
• Two access logs can be concatenated using a bit-wise OR operation.
• the Service Conduits are typically processes, services and files. An access log is associated to each process and file. For each service it is annotated whether the service is provided in the same direction as the information flow, in the reverse direction or bi-directionally with respect to the initiator/responder relationship of the communication flow.
• Any file can be considered as a service conduit. If a program reads or writes to a file then the access logs of the file and the program are updated according to the annotations of the service identifiers.
• a system call that allows setting the colour of a pixel could be used to covertly relay access to a service past the access control constraints.
• any covert channel between programs can be used for this purpose. If IPC is performed between a service and such a program that is not a service then a service identifier of the service in question is appended to the access log of the program.
• Networking protocols can be used to communicate between principals outside of this framework even within the host operating system.
• removable media or analogue channels such as from speaker to microphone or from screen to camera. This should be considered in the definition of access control constraints. This applies to any system that attempts to access control information in the presence of external communication channels (be they analogue or digital). Notice that many user interface functions can double up as an analogue I/O channel between programs.
• the access control server is capable of computing the sets of principals and evaluating the access control constraints.
• the access control server can be software based and provided by the processor 130.
• the IPC and file system infrastructure are modified to propagate and manage the access logs and query the access control server whenever a new service identifier would be added to an access log.
• the services that would need modifying are part of the Trusted Computing Environment. Especially care should be taken with respect to any present covert channels.
• the presence of DRM support in Symbian 9 may resolve the cases where processes are not co-operating, but more advanced implementations should further consider covert channels for co-operating processes. Even if covert channels could not be completely barred, they are made relatively inefficient in an embodiment of the invention.
• such an access control constraint can be defined that prohibits the use of the microphone while there exists a process that has the DRM service identifier set in its access log. This substantially prohibits "re-digitizing" content using the same handset that is playing it.
• the following constraint can be defined: If DRM content is read by a program that does NOT have the DRM capability set, then disable the use of services that set a "non-UI" service identifier, except for the "file read” identifier. Hence, such non-certified DRM capable player programs can be run that are able to read instructions and/or commands from a file. The constraint prevents this player program from communicating information by any other means but the user interface.
• OS capabilities are divided into two categories, user capabilities and system capabilities.
• User capabilities are a small and relatively easily understandable set of capabilities which can be presented to owners of a device when they are installing applications. The user capabilities enable the users to check that the application should not perform any unexpected operations when used.
• System capabilities are not transparently presented to the user. Instead, the system capabilities are concealed from the users. This is because not all the implications of system capabilities are easily understood users.
• NetworkServices - access to remote services without any restriction on its physical location. Typically, this location is unknown to the phone user. In addition, such services may incur cost for the phone user.
• LocalServices access to remote services in the close vicinity of the phone.
• the location of the remote service is well-known to the phone user. In most cases, such services will not incur cost for the phone user.
• ReadUserData* read access to data confidential to the phone user. This capability supports the management of user's privacy. Contacts, messages and appointments are always seen user confidential data. For other contents such as images or sounds, it may depend.
• WriteUserData* management of the integrity of user data. Please note that this capability is not symmetric with ReadUserData. For instance, one may wish to prevent rogue applications to delete music tracks but may not wish to restrict read access to them. If it is clear that all private data are user data, but the choice of confidential data is more arbitrary and may depend of the UI implementation.
• Location access to the location of the device. This capability supports the management of user's privacy regarding the phone location.
• ReadUserData and WriteUserData are provided to protect the user's privacy. Not all the data of a mobile phone, for example, have to be protected by these capabilities. There are a number of use cases where particular application data may be either private or public as far as the user is concerned. Still images and video footages, for instance, may be either rather neutral or very sensitive depending on their subject. Contacts, mail and calendar entries are typically personal. It is rather unimportant whether anyone sees the public data, but usually the private data should be protected from undesired access of other people and malicious software, that is, malware.
• the UI specification should account for these issues and provide means for protecting private data. The protection can be carried out, for example by using password protection, dividing data into different folders depending on the desired accessibility of given data (e.g. type of data), or by any combination of these.
• system capabilities include one or more of the following items:
• multimedia device drivers for multimedia devices such as sound device, camera, video device.
• multimedia devices such as sound device, camera, video device.
• DRM agents use this capability to decide whether an application should have access to DRM content. Applications being granted DRM are trusted to respect the rights associated with this content.
• Trusted UI dialogs are rare, mainly used when confidentiality and secure are critical, as with password dialogs, for instance. Normal access to the user interface and the screen does not require this capability.
• NetworkControl For instance, forcing all existing connections on a specific protocol to be dropped or changing the priority of a call.
• Symbian Platform Security model allows servers to control access to their APIs without knowing their requesters and therefore avoids the need of maintaining an access control list.
• SID Secure Identifier
• VID Vendor Identifier
• the SID is an identifier that is guaranteed to be locally unique.
• the VID is contained by executable files in order to provide for a unique identification of the source of a given executable file. In most cases, this VID is zero, that is, the source of the executable file is not needed for any security checks.
• Fig. 3 shows a flowchart representing the operation according to an embodiment of the invention.
• the flowchart starts from step 300, in which the terminal idles.
• step 310 the first arbitrary application is started. This application uses one functional block of the radio block for streaming down media content.
• the terminal checks in step 320 that no access constraints forbid the use of the radio block by the first application. If any forbidding constraints found, the access is denied and the application may be stopped and / or the application may provide an error message, and the process resumes to step 300. Otherwise, in step 330, the terminal recognises the type of the media content to be received and starts a third-party media player, configured by the user as a preferential player for that media type.
• step 360 it is checked if any access constraints are violated. Assuming none, the terminal proceeds to step 350. Then, a called service or resource starts, such as playing back the content (that is being streamed down) using the media player. If the check of step 360 results yes, the terminal prohibits 370 the recording because of a forbidden conjunction of used functions. Next, the operation resumes to step 310.
• An embodiment of the invention involves creating mutually exclusive access conditions in an access control system.
• the embodiment may selectively enable performing any one of plural operations alone but not in combination with another operation.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• Computer Security & Cryptography (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (1)

Publications (2)

Family

ID=38327146

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Citations (2)

Family Cites Families (5)

• 2006
  • 2006-02-01 JP JP2008551809A patent/JP2009524864A/ja not_active Withdrawn
  • 2006-02-01 WO PCT/FI2006/050050 patent/WO2007088237A1/en active Application Filing
  • 2006-02-01 CN CN200680052134.1A patent/CN101336415A/zh active Pending
  • 2006-02-01 EP EP06708954A patent/EP1979812A4/de not_active Withdrawn

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events