Patent Publication Number: US-11641581-B2

Title: Security management on a mobile device

Description:
RELATED APPLICATION(S) 
     This application is a continuation of U.S. patent application Ser. No. 16/119,427 filed Aug. 31, 2018, which is a continuation of U.S. patent application Ser. No. 14/089,942 filed on Nov. 26, 2013 (now U.S. Pat. No. 10,070,315). All sections of the aforementioned applications and patents are incorporated herein by reference in their entirety. 
    
    
     BACKGROUND 
     The present disclosure relates generally to security management on mobile devices. Mobile devices, such as smartphone and tablets, are quickly becoming the dominant platform over which cloud services and content are consumed. For example, many workplaces now allow employees to use their own personal mobile devices to access employer resources (e.g., bring your own device or BYOD). One challenge faced by users of mobile devices is preventing the co-mingling of personal information and workplace information. 
     One exemplary existing solution allows a user to create separate personal and workplace environments on the same device. The enterprise data and applications are hosted in the cloud, and consumed from the mobile device using a thin-client solution. This architecture results in duplication for the user. Duplication also occurs when virtual machines running on the phone or other sandboxed environments on are used. For example, the user may run different email applications for the personal environment and for the workplace environment, different applications for reading/modifying content (PDF files, etc.), different settings applications, etc. Furthermore, the applications made accessible in the workplace environment have to be individually certified to ensure that they do not leak sensitive data to unauthorized parties. 
     BRIEF SUMMARY 
     Exemplary embodiments include a method for managing security levels on a mobile device, the method including receiving a capsule including first data; assigning a first data tag to the capsule, the first data tag identifying a security level for the first data; storing the capsule on the mobile device; executing a process on the mobile device, the process associated with an application tag; allowing the process to access the first data when the application tag matches the first data tag, the process for generating second data in response to the first data. 
     Other exemplary embodiments include an apparatus including a processor; and memory comprising computer-executable instructions that, when executed by the processor, cause the processor to perform operations, the operations including receiving a capsule including first data; assigning a first data tag to the capsule, the first data tag identifying a security level for the first data; storing the capsule on the mobile device; executing a process on the mobile device, the process associated with an application tag; allowing the process to access the first data when the application tag matches the first data tag, the process for generating second data in response to the first data. 
     Other exemplary embodiments include a computer program product, tangibly embodied on a non-transitory computer readable medium, for managing security levels on a mobile device, the computer program product including instructions that, when executed by a processor, cause the processor to perform operations including receiving a capsule including first data; assigning a first data tag to the capsule, the first data tag identifying a security level for the first data; storing the capsule on the mobile device; executing a process on the mobile device, the process associated with an application tag; allowing the process to access the first data when the application tag matches the first data tag, the process for generating second data in response to the first data. 
     Other systems, methods, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, and/or computer program products be included within this description, be within the scope of the exemplary embodiments, and be protected by the accompanying claims. 
    
    
     
       BRIEF DESCRIPTION OF EXEMPLARY EMBODIMENTS 
       Referring now to the drawings wherein like elements are numbered alike in the several FIGURES: 
         FIG.  1    depicts a mobile device in an exemplary embodiment; 
         FIG.  2    depicts an architecture for security management in an exemplary embodiment; 
         FIG.  3    depicts a capsule in an exemplary embodiment; and 
         FIG.  4    is a flowchart of a process for security management in an exemplary embodiment. 
     
    
    
     The detailed description explains the exemplary embodiments, together with advantages and features, by way of example with reference to the drawings. 
     DETAILED DESCRIPTION OF DRAWINGS 
       FIG.  1    illustrates a mobile device  10  according to an exemplary embodiment. Mobile device  10  may be a phone, tablet, personal digital assistant, etc., equipped with communications components (e.g., cellular, wireless LAN, NFC, Bluetooth, USB) for communicating over wireless or wired communications mediums. Mobile device  10  includes a display  14  such as an organic light emitting diode (OLED) display or liquid crystal diode (LCD) display, a microphone  16  used for voice communications and for receiving spoken commands from a user, a camera  18 , a speaker  20  that provides audio output to the user, and one or more buttons  24  for controlling the device. Buttons  24  may be permanent components built into a housing or may be virtual buttons, presented on display  14 , activated by touching display  14 . One or more sensors  22  may be used to sense various parameters such as location (e.g., GPS receiver), etc. 
     A processor  40  controls operation of mobile device  10 . Processor  40  may be implemented using a general-purpose microprocessor executing a computer program stored in a computer readable storage medium  43  to execute the processes described herein. Processor  40  may include memory (e.g., RAM) for loading programs for execution. Storage medium  43  provides storage accessible by applications  41 . Storage medium  43  provides for storage of capsules defining security levels associated with data and applications on the mobile device  10 . Processor  40  executes an operating system  45  and a number of applications  41 , such as an email application, a calendar application, etc. 
     Processor  40  is also coupled to a communications unit  42  that handles communications between the mobile device  10  and other devices, such as cellular phone calls, NFC communications, Bluetooth, etc. The communications unit  42  is configured to communicate over a wireless network and may also include a port (e.g., USB) for wired connections. 
       FIG.  2    depicts architecture  100  for security management on mobile device  10  in an exemplary embodiment. As data is received from a data source, a secure tagging function  102  assigns a tag to the data. The data source may be external to the mobile device (e.g., retrieved from a server) or generated at the mobile device (e.g., a photo taken by the camera). Prior to any data being stored, the data is assigned a data tag that is used control access to the data and control propagation of the data, both internal and external to the mobile device  10 . Tags assigned to data may be used to prevent data with different tags from being mixed. As data is accessed and processed, the tag associated with that data may change. Data tags are also propagated, i.e., if new data is produced by the processing of tagged data, it inherits the data tag of that processed data. This ensures that data that may be derived from tagged data also stays within the same security-perimeter. Applications may be assigned an application tag based on what operations are being performed, what data is accessed, and/or the environment where the mobile device is operating. Managed applications (e.g., those that run in an instrumented runtime environment) may also process data having multiple tags as long as the managed applications do not mix data having different tags or violate security policies associated with the tags. 
     The secure tagging function  102  may assign a tag to the data based on a capsule that incorporates the data and a data tag. The capsule may be considered similar to an encrypted folder containing the data and other fields and defines a micro-security perimeter.  FIG.  3    shows an exemplary capsule  200  having data  202  (e.g., a document from the workplace), a unique capsule identifier  206  and an owner  208 . It is understood that other fields may be incorporated into the capsule  200 . For example, if user credentials  210  are needed to access the data (e.g., a pin, user login and password), these fields may be incorporated in capsule  200  as well. When the tagged credentials are used to access an external resource (e.g., an email server), any data that comes back (e.g., an email), will be tagged with the same tag, so as to ensure that the retrieved data is in the same security perimeter as the credentials provided in the capsule. Capsule  200  may include a security/mixing policy that requires the user to enter a passcode when any data in the capsule is accessed by an application. Such a policy may also require the data in the capsule  200  to be decrypted only after the passcode is entered, is to prevent data access when a device is lost, stolen, etc. 
     Referring back to  FIG.  2   , secure tagging function  102  receives capsule  200  and associates a data tag with data  202 , prior to storing capsule  200  on the mobile device (e.g., on storage medium  43 ). It is understood that instead of data  202 , capsule  200  may include an application for installation on mobile device  10 . In this case, an application tag is assigned to the application contained in the capsule  200 . It is noted that the data tag and/or application tag may be neutral, for example, not initially associated with a particular environment (e.g., personal or workplace). 
     Architecture  100  includes an operating system level  104 . Operating system level  104  implements a system call tag tracking application  106  that tracks data tags and application tags between processes executing on mobile device  10 . Operating system level  104  also implements a system call security enforcement application  108  that allows or prevents operations based on the data tags and application tags. The system call tag tracking application  106  and system call security enforcement application  108  assign data tags and application tags during interaction between processes to prevent mixing of data tags and/or application tags of different types, and to propagate the appropriate data tags and/or application tags upon execution of processes. Operating system level  104  may be referred to as managing security between processes or inter-process. 
     Architecture  100  includes an application runtime level  110 . Application runtime level  110  provides a runtime environment (e.g., Android Dalvik) for applications executing on the mobile device  10 . Application runtime level  110  implements an application tag tracking application  112  that tracks data tags and application tags within a process executing on the mobile device  10 . Application runtime level  110  also implements an application security enforcement application  112  that allows or prevents operations based on the data tags and application tags. The application tag tracking application  112  and application security enforcement application  114  assign data tags and application tags within a process to prevent mixing of data tags and/or application tags of different types, and propagate the appropriate data tags and/or application tags upon execution of a process. Application runtime level  110  may be referred to as managing security within a process or intra-process. 
     An application program interface level  120  provides a mechanism for an application  122  executing on mobile device  10  to generate an application program interface call  124  to the operating system level  104  to determine a data tag and/or an application tag for data and/or an application that the executing application  122  is accessing. The application  122  can then reflect the nature of the data tag and/or application tag in an application user interface  130 . For example, a document reader application accesses a document, and generates an application program interface call  124  to the operating system level  104  to determine a data tag for the document. The document reader interface can be displayed in response to the data tag (e.g., yellow for workplace document, green for personal document). Similarly, an email application may present personal emails in a first color and workplace emails in a second color. 
       FIG.  4    is flowchart of processing performed by mobile device  10  to manage security in an exemplary embodiment. The process begins at  300  where capsules  200  are received at the secure tagging function  102 . As described above with reference to  FIG.  2   , capsules  200  are stored on mobile device  10  along with the appropriate data tag and/or application tag at  302 . At  304 , an application executing on mobile device  10  initiates a call. If the call is an inter-process call, flow proceeds to  306 . At  306 , system call tag tracking application  106  determines the application tag associated with the calling process. At  308 , system call tag tracking application  106  determines the application tag associated with the called process. At  310 , the system call security enforcement application  108  determines if the calling process is prohibited from accessing the called process based on the application tags associated with the calling process and the called process (and the security policy, e.g., what kind of mixing is allowed, if at all). The application tags of the calling process and the called process are considered to match if the application tags of the calling process and the called process do not conflict. For example, the application tags of the calling process and the called process may be identical, thereby permitting access. Alternatively, one of the application tags of the calling process and the called process may be neutral, thereby allowing access. Both such cases are considered a match. 
     If at  310 , the application tags of the calling process and the called process match, flow proceeds to  312  where the access is permitted. The application tag for the current instance of the calling process may be updated to reflect access to the called process (also, the tag of the called process may be updated if data flows from the caller to the callee). If at  310 , the application tags of the calling process and the called process do not match, flow proceeds to  314  where the access is prohibited. At  314 , the user may be notified of the prohibited access through user interface  130 . 
     If at  304 , the call is an intra-process call, flow proceeds to  316 . For intra-process tag propagation, the application runtime environment  110  tracks each instruction and tags all the individual data or memory objects. At  316 , application tag tracking application  112  determines the application tag associated with the process. At  318 , application tag tracking application  112  determines the data tag associated with the data. At  320 , the application security enforcement application  114  determines if the process is prohibited from accessing the data based on the application tag associated with the process and the data tag. The application tag of the process and the data tag are considered to match if the application tag of the process and the data tag do not conflict. For example, the application tag of the process and the data tag may be identical, thereby permitting access. Alternatively, one of the application tag and the data tag may be neutral, thereby allowing access. Both such cases are considered a match. In other embodiments, the resultant of the processing of the data is observed by application security enforcement application  114 . If the data tag of the output of the process does not match the data tag of the data, then execution of the process can be terminated to prevent the resultant of the process from being output. For example, an application cannot access personal data and output a resultant workplace data. This prevents co-mingling of different types of data. 
     If at  320 , the application tag of the process and the data tag match, flow proceeds to  322  where the access is permitted. The application tag for the current instance of the process may be updated to reflect access to the data. For example, if an email process access a workplace address or workplace document, then that email instance is assigned the workplace data tag. Further, any data output by the process may be assigned the data tag, so that the data tag propagates through the system. If at  320 , the application tag of the process and the data tag do not match, flow proceeds to  314  where the access is prohibited. At  314 , the user may be notified of the prohibited access through user interface  130 . 
     Examples of operation of the system are provided to illustrate exemplary embodiments. In one example, a user accesses an email process running on mobile device  10 . Initially, the email process may have no application tag. As the user composes an email, the email process makes a system call through operating system level  104  to an address book process to obtain an email address. The email address, for example, is associated with a data tag (e.g., personal) and thus, the system call tag tracking application  106  assigns a similar application tag to the email (e.g., personal). For sake of illustration, assume the user now attempts to attach a business document to the email. The business document is associated with a data tag of a different type (e.g., workplace). The system call security enforcement application  108  prevents the business document from being attached to the email, as the data tag does not match the application tag. The user would be notified of the prohibition. 
     In another example, a user obtains a picture using camera  18 . Prior to storage, the picture is received at secure tagging function  102 , in a capsule generated by the camera process. Capsule  200  may be associated with different data tags for the picture depending on the location and/or time when the picture was taken, as determined by sensors  22 . If mobile device  10  is within a certain area (e.g., the workplace) or taken during a certain time (e.g., work hours), the capsule containing the picture is associated with a workplace security level. If mobile device  10  is outside the certain area or time (e.g., on vacation) the capsule containing the picture is associated with a personal security level. 
     In another example, a user downloads a video to mobile device  10 . The video is contained in capsule that provides digital rights management for the video. The capsule is assigned a data tag that prevents the video from leaving mobile device  10 , so that attempting to email, upload, or otherwise transmit the video would be prohibited. This allows the user of mobile device  10  to view the video using any viewer installed on mobile device  10 , rather than a viewer required by the supplier of the video to manage digital rights. 
     Embodiments described herein provide fine-grained policy based data-protection as a first class primitive in a mobile device operating system so that the user doesn&#39;t have to maintain completely different environments for different categories of data stored on the mobile device. This allows individual data and applications to be contained in micro-security perimeters, referred to as capsules. These capsules can be securely installed on a phone, and are subject to a data security policy defined by the capsule owner. The policy may specify what kinds of data mixing is allowed, and can be a function of the current security context. The operating system tracks the flow of data on a per-capsule basis as it is used by applications on the phone, and enforces the security policies associated with the capsules. 
     As described above, the exemplary embodiments can be in the form of processor-implemented processes and devices for practicing those processes, such as processor  40 . The exemplary embodiments can also be in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a device for practicing the exemplary embodiments. The exemplary embodiments can also be in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into an executed by a computer, the computer becomes an device for practicing the exemplary embodiments. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits. 
     While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed for carrying out this invention, but that the invention will include all embodiments falling within the scope of the claims. Moreover, the use of the terms first, second, etc., do not denote any order or importance, but rather the terms first, second, etc., are used to distinguish one element from another. Furthermore, the use of the terms a, an, etc., do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.