Patent Document

CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Patent Application No. 61/604,848, filed Feb. 29, 2012, the entirety of which is incorporated herein by reference. 
     
    
     FIELD OF THE DISCLOSURE 
       [0002]    This relates to mobile device security, and more particularly, to providing mobile device security through the use of a charging station. 
       BACKGROUND 
       [0003]    Measuring and attesting to the operational integrity and security posture of a mobile device is challenging. For example, smart phones and tablet computers currently lack a number of traditional security features that have emerged for commodity laptops and desktops. In addition to restricted power, mobile devices generally don&#39;t have a Trusted Platform Module (TPM) and currently lack ubiquitous virtualization capability, which limits some current approaches to security. Even as these security mechanisms reemerge for mobile devices, no single one is expected to be a “silver bullet.” 
         [0004]    Black-listing and, in general, malicious signature detection has proven to be ineffective against polymorphic malware and other attacker techniques. Virus scanning, virtual machine introspection and taint tracing can also deplete a device&#39;s battery faster than normal. [Deepak Venugopal, An efficient signature representation and matching method for mobile devices, In Proceedings of the 2nd annual international workshop on Wireless internet, WICON&#39;06, New York, N.Y., USA, 2006, ACM.] Battery drain is a critical aspect of a consumer&#39;s experience with mobile devices—a security mechanism that tips the balance of this reality will undoubtedly be met with disdain by consumers and unlikely to be adopted by vendors. 
       SUMMARY 
       [0005]    By taking advantage of the need to recharge mobile devices, a hygienic smart charger can be provided to measure, attest, and remediate the integrity of hosted mobile devices via a peripheral interface such as the Universal Serial Bus (USB) while the mobile device recharges. This can provide an alternative defensive security strategy for devices with inherently limited power. 
         [0006]    In one embodiment the charger can take the form of a plug computer with embedded adaptable logic to analyze a security state of a mobile device. Such analysis can include gathering evidence of the side effects caused by malicious activity whether on non-volatile storage or in-memory. These observations can be made at different layers of the operating system (OS) stack with the phone in different states. 
         [0007]    For example, measurements can be obtained on-device while the main OS is running, externally on the charger via a peripheral interface and debugging mechanisms, and by placing the phone into a minimalistic recovery state—typically used for forensics—where a smaller execution context is used to check the device&#39;s integrity. Since malware has different persistence mechanisms, measurements from different vantage points can warrant different types of remediation such as a straightforward response of re-flashing the entire mobile device to a master image. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  illustrates an example of a hygienic charging operation in accordance with one embodiment. 
           [0009]      FIG. 2  illustrates an example of a charger apparatus in accordance with one embodiment. 
           [0010]      FIG. 3  illustrates an example of a system architecture of a charger in accordance with one embodiment. 
           [0011]      FIG. 4  illustrates an example of a hygienic charging operation in accordance with one embodiment. 
           [0012]      FIG. 5  illustrates an example of a hygienic charging operation in accordance with one embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0013]    Malware can easily be embedded into mobile devices. For example, an adversary could gain an initial presence on a user&#39;s device by crafting a malicious app and placing it on an online app store such as the ANDROID Market. The app could provide features bundled with a malicious payload. It is assumed that the app store owner makes a best effort to remove applications that are determined malicious, but such detection can be made increasingly difficult by an attacker, resulting in a time delay that could allow malware some period of efficacy. Alternatively, the user may be tricked into downloading a malicious application from a third-party market with a spear phishing attack. 
         [0014]    For example, applications on AN DROID devices use an all-or-nothing permissions model. Many users don&#39;t understand the risks inherent in these permissions. For example, how could a user know that granting access to a phone&#39;s crash-log information could aid in escalating an application&#39;s privileges to root privileges, as in the case of GingerBreak? [Xuxian Jiang, Gingermaster: First ANDROID malware utilizing a root exploit on ANDROID 2.3 (gingerbread), August 2011.] [Xuxian Jiang, Security alert: New rootsmart ANDROID malware utilizes the gingerbreak root exploit, February 2012.] [Vanja Svajcer, First malware using ANDROID gingerbreak root exploit, August 2011.] Alternatively, a sophisticated attacker could target a user&#39;s other computing devices (e.g., personal laptop or desktop) and wait for the user to plug in the mobile device. Laptops and desktops suffer from large attack surfaces because they are general purpose computing devices often used to access rich media. 
         [0015]    Integrity violations introduced by malicious software can be dependent on the device&#39;s existing security mechanisms. Examples of integrity violations include 1) changes to the bootloader, which is the first code to execute on a mobile device at boot time (e.g., a bootkit), 2) replacing the kernel entirely and/or modifying kernel data structures at runtime to hide malicious activity (e.g., a rootkit), 3) implanting native binaries that obfuscate application-layer malware analysis, 4) implanting of managed-code rootkits into virtual machine (VM) applications (e.g., the DALVIK VM) and associated data structures, 5) modifying permissions on key system files (e.g., SUID-bits), allowing other malware components a mechanism to hide in plain sight and 6) marking good storage blocks bad and using them for covert data storage. 
         [0016]    Further, detecting and mitigating integrity violations can depend on a mobile device vendor&#39;s implementation of the mobile device. For example, replacing the bootloader on some devices can be infeasible because this critical software must be signed using a private key only the vendor has, and the bootloader is verified using a corresponding burned in public key that cannot be changed by conventional means. In order to be usable, some region of the devices storage must be read/write, and thus could be used for persistence by malware. 
         [0017]    The proliferation of malicious software on mobile devices is only going to get worse. However, power constraints on mobile devices limit the capabilities/techniques that can be applied on low power devices such as smartphones and tablet computers. Since these devices are plugged in (e.g., to a wall plug or PC USB port) or “docked” (e.g., to a docking station) often—sometimes on a daily basis—to replenish the battery, this presents an opportune time, during which the device is largely idle, in which to determine the security posture of the device. While not all attack vectors may be averted, it can raise the bar for an attacker, in particular making persistence increasingly challenging. 
         [0018]    Recharger devices have traditionally been simple devices, such as alternating current (AC) to direct current (DC) power adapters whose intelligence is used to control the power-rate at which a device is charged (i.e., in a way that is most efficient to the life of the battery). However, it is believed that a hygienic charger can help mitigate the risk of persistent malicious software on mobile devices and aid in raising the bar for a sophisticated attacker to be successful in the attacker&#39;s mission. 
         [0019]      FIG. 1  illustrates an example of a hygienic charging operation in accordance with one embodiment. As shown in  FIG. 1 , charger  100  can be configured to recharge mobile device  110  by providing power from power source  120  and to communicate with mobile device  110  to analyze a security state of the mobile device, such as whether and/or to w hat degree the mobile device presents indications of compromise or is otherwise in a state that it should not be in. As part of this security analysis, charger  100  can be configured to perform a variety of security measures in addition to recharging the mobile device battery, such as performing platform integrity checking, providing secure (cryptographic) storage of sensitive information, storing a master image of the mobile device, aiding in repurposing the mobile device from a personal phone to a business platform for the duration of business/sensitive operations, periodically re-flashing a known-good “golden” image to eliminate persistence of malicious software (e.g., keyloggers, rootkits, trojans), provisioning a cryptographic token indicating the mobile device has been analyzed by charger  100 , and using the cryptographic token to allow access to a protected network (e.g., VPN) or data. 
         [0020]      FIG. 2  illustrates an example of a charger apparatus in accordance with one embodiment. As shown in  FIG. 2 , charger  100  can comprise housing  200  with power interface  210  and peripheral interface  220 . Power interface  210  can comprise any suitable interface configured to connect to power source  120 , such as prongs protruding from housing  200  (e.g., an integral male plug) configured to plug directly into power source  120  (as shown in  FIG. 2 ), an integrated or connectable power cord or a wireless power interface. Peripheral interface  220  can comprise any suitable interface configured to connect to mobile device  110 , such as a Universal Serial Bus (USB) port. Additional interfaces (not shown) can be provided on the housing, such as storage interfaces (e.g., a memory card slot), input interfaces (e.g., buttons) and output interfaces (e.g., lights). 
         [0021]    Charger  110  can comprise an embedded system such as “plug” computer configured to plug directly into a power outlet. Plug computers have become less expensive, ubiquitous and sufficiently powerful, and thus provide a small form-factor system on chip (SoC) design that can be used to meet the requirements of a “smart” hygienic charger device in accordance with the teachings of the present disclosure. 
         [0022]    In particular, charger  100  can implement in-built debugging/recovery mechanisms that become available upon mobile devices being plugged into charger  100  as a host system via peripheral interfaces (e.g., USB host interface). Charger  100  can be configured with a smaller attack surface than that of a typical laptop/desktop while also being outside the critical path of an attacker. In addition, charger  100  need not be directly network accessible (e.g., it can receive encrypted update modules via mobile device  110 ) or support the execution of rich media formats such as PDF, Flash, or be usable as a web browser. This reduced functionality and specialization can reduce the attack surface significantly and can be leveraged by an enterprise associated with the mobile device. In one embodiment charger  100  can be implemented using the SheevaPlug plug computer which is a Marvell Kirkwood (ARM-based) platform with USB host connectivity. 
         [0023]      FIG. 3  illustrates an example of a system architecture of a charger in accordance with one embodiment. In the illustrated embodiment charger  100  can comprise power manager  300 , processor  310  and storage  320 . Power manager  300  can comprise any suitable circuitry configured to provide power from power source  320  to mobile device  110 , such as circuitry configured to draw AC power of power source  320  from a standard connector and adapt the AC to DC suitable for mobile device  110  (e.g., providing the 5V and up to 500 mA power supply to the mobile device for charging). Processor  310  can comprise any suitable circuitry, such as a cryptographic processor, capable of running an OS configured to analyze a security state of the mobile device in accordance with the teachings of the present disclosure, such as a minimalistic OS that is specifically configured to execute pre-set sanity checks on mobile device  110 . Storage  320  can comprise any suitable storage, such as non-volatile storage (e.g., NAND, disk drive), configured to store data in accordance with the teachings of the present disclosure, such as a recovery or boot image for mobile device  110  and/or a public key of an enterprise server associated with mobile device  110 . 
         [0024]      FIGS. 4 and 5  illustrate ways in which charger  100  can analyze the security state of mobile device  110  comprising a NEXUS S ANDROID-based mobile phone.  FIG. 4  illustrates an example of a hygienic charging operation in which charger  100  stores on mobile device  110  an image comprising instructions to analyze the security state of mobile device  110  and subsequently instructs mobile device  110  to boot into that image.  FIG. 5  illustrates an example of a hygienic charging operation in which charger  100  instructs mobile device  110  to boot into the image having been loaded directly into memory of mobile device  110 . 
         [0025]    As illustrated in  FIG. 4 , upon detecting mobile device  110  being connected to/plugged into charger  100  (block  400 ), charger  100  can commence analysis of a security state of mobile device  100 . Charger  100  can commence the security analysis automatically (i.e., without user input via an input interface of charger  100  or mobile device  110 ) or in response to user input (e.g., via an input interface of charger  100  or mobile device  110 ). In an embodiment in which charger  100  commences the security analysis automatically, user input is not solicited to commence the security analysis although user input m ay be solicited throughout the security analysis after it has commenced. 
         [0026]    Once commenced, the security analysis can include charger  100  instructing mobile device  110  to flash a recovery image to a recovery partition (e.g., a NAND partition) of mobile device  110  (block  410 ). Although a recovery image and a recovery partition are disclosed in this embodiment, any suitable type of image can be flashed or stored to any suitable location in the non-volatile storage of mobile device  110  in accordance with the teachings of the present disclosure. 
         [0027]    Flashing an image to a partition generally refers to the process of erasing the current contents of a partition (usually stored in updatable “flash” memory) and replacing it with the contents of the image (i.e., data) to be flashed. In order to accomplish this, charger  100  can first induce mobile device  110  to reboot in a bootloader mode. 
         [0028]    Charger  100  can utilize Android Debug B ridge (ADB)—an in-built mechanism of the ANDROID device—or other suitable software on mobile device  110  to reboot into bootloader mode. If such software is not available on mobile device  110 , charger  100  can instruct the user via the user interface (screen) of mobile device  110  to reboot into bootloader mode (e.g., by powering down then pressing the volume up button and power button simultaneously). It can be assumed that the bootloader is signed by the vendor. 
         [0029]    Upon reboot into bootloader mode, the bootloader of mobile device  110  can implement a protocol such as fastboot to provide a communication pathway through which charger  100  can instruct the flashing of the recovery image to the recovery partition of mobile device  110 . 
         [0030]    The recovery image can comprise instructions (e.g., a custom Kernel and ramdisk image) to analyze the security state of mobile device  110  and thus implementing a mobile device side of any suitable security measure such as those described above. The recovery image can be stored in storage  320  of charger  100  (e.g., in a signed/encrypted format) or can be supplied in a known location on mobile device  100  (e.g., in a signed/encrypted format). If stored on mobile device  110 , malware on mobile device  110  would not be able to change the recovery image because the private key can be stored in the enterprise, similar to the mechanism used to protect the bootloader. However, storing the recovery image on charger  100  provides the advantage of keeping the public key of the enterprise on charger  100  without mobile device  110  having access to it. 
         [0031]    Thus, in response to charger  100  instructing mobile device  110  to flash the recovery image to a recovery partition of mobile device  110 , mobile device  110  can implement the flash operation (block  420 ). Charger  100  can subsequently instruct mobile device  110  to automatically boot into the recovery image (block  430 ). In response, mobile device  110  can boot into the recovery image (block  440 ), causing mobile device  110  to execute the recovery image instructions (block  450 ) which can comprise any security measure contained therein. The recovery image can be a reasonable size (e.g., less than 4 MB) and can include a software self-checking mechanism (e.g., checksum, MD5 hash of memory contents, etc.) to verify that it has been properly booted. 
         [0032]    The recovery image can act similar to a Live CD on a traditional laptop/desktop. For example, the custom recovery image can cause mobile device  110  to mount its file system and begin to look for indications of compromise (e.g., incorrect checksums of system libraries, kernel, kernel modules, native binaries, permissions). It should be noted that trust is placed on the bootloader and the underlying hardware of the device to not actively hide malicious activity; everything else can be treated as untrustworthy. It should also be noted that the operating environment of mobile device  110 , once in recovery mode, does not use drivers or filesystem loaders of the possibly compromised mobile device, but of those that were built into the custom recovery image. 
         [0033]    Once mobile device  110  has completed looking for indications of compromise, it can provide the results of its security scan to charger  100  for processing (block  460 ). Should charger  100  determine that the results indicate that mobile device  110  is compromised, charger  100  can take action to remedy the compromised state of mobile device  110 , such as zeroizing mobile device  110  (e.g., overwriting its partitions to render it inoperable) thereby forcing the user to return mobile device  110  to the enterprise for re-provisioning. Alternatively, charger  100  can store a signed gold m aster recovery image that can be used to re-provision the device at the time of detection. This gold master recovery option can comprise wiping mobile device  110  of all data and reconstituting the user&#39;s data by downloading it from the enterprise via a network. The processing of the security scan results can be divided among charger  100  and mobile device  110  in any suitable manner, including a joint effort in which charger  100  and mobile device  110  process the data together via timing-based attestation for example. 
         [0034]    Once the security measures have been cleared, using its cryptographic processor charger  100  can deposit a time-sensitive secure token that indicates mobile device  110  has passed the pre-defined checks. The tokens can form a basis on which the enterprise can allow mobile device  110  to access private networks and resources of the enterprise that would have otherwise been off-limits. Charger  100  can also digitally sign measurements associated with the security state of mobile device  110  (e.g., data such as offsets of libraries, heuristics, etc., compiled by mobile device  110  when looking for indications of compromise), and provide the signed measurements to the enterprise to form a basis on which the enterprise can decide to grant or deny access to mobile device  110  (e.g., via security protocols such as SASL and/or IKE). Upon completion of the security analysis, charger can continue to charge mobile device  110  (block  470 ). 
         [0035]    The hygienic charging operation can be time efficient, taking a small amount of time such as less than three minutes in situation in which re-provisioning is not required. Charger  100  can also employ other policy decisions in implementing the hygienic charging operation, such as automatically re-provisioning if a set amount of time has lapsed since the last operation (e.g., one day). 
         [0036]    Each mobile device can require a different set of measurements/analysis that must be done on charger  100 . While a class of device (e.g., ANDROID devices) can be lumped together, each mobile device vendor can also have a different configuration that can require a customized capability on the charger. In such situations, charger  100  can therefore be tied to a particular individual&#39;s phone. 
         [0037]    As illustrated in  FIG. 5 , rather than writing to non-volatile storage (e.g., the NAN D partition) as depicted in the embodiment of  FIG. 4 , charger  100  can utilize a “direct boot” or “one shot” booting mechanism that loads the image directly into mobile device  110 ′s memory (e.g., RAM) and transfers execution to it. Such a booting mechanism is supported by the fastboot protocol, for example, and allows for booting a boot image (the equivalent of the recovery image described above) without the inconvenience of erasing the existing recovery partition on non-volatile storage, thus allowing the normal use of that partition for other purposes if desired by the user. Utilizing a one shot boot can therefore be less intrusive on mobile device  110  than the flashing embodiment described above. 
         [0038]    Blocks  500 ,  530 ,  540 ,  550  and  560  generally correlate to blocks  400 ,  440 ,  450 ,  460  and  470 . The one shot embodiment of  FIG. 5  differs from the flashing embodiment of  FIG. 4  in that charger  100  can instruct mobile device  110  to boot a boot image (equivalent in functionality to the recovery image described above) directly into mobile device  110 &#39;s memory (block  510 ). Upon receipt of this instruction, mobile device  110  can load the boot image (which can be stored on charger  100  or supplied in mobile device  100  as described above in connection with the recovery image) into its memory (block  520 ) and automatically boot into the boot image (block  530 ) thereafter. 
         [0039]    It will be appreciated that the above description for clarity has described some embodiments of the disclosure with reference to single steps. However, it will be apparent that any suitable distribution of functionality among each step can be used without detracting from the disclosure. For example, functionality illustrated to be performed in a single step may be performed in multiple steps. Hence, references to specific steps may be seen as providing the described functionality rather than indicative of a strict logical or physical structure or organization. 
         [0040]    The circuitry of charger  100  can be implemented in any suitable form, including hardware, software, firmware, or any combination of these. The circuitry can also be implemented partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of the circuitry can be physically, functionally, and logically implemented in any suitable way. Indeed, the functionality can be implemented in a single unit, in a plurality of units, or as part of other functional units. As such, the circuitry can be implemented in a single unit or may be physically and functionally distributed between different units and processors. 
         [0041]    The instructions described above can be stored and/or transported within any computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a computer-readable storage medium can be any medium, such as storage  320 , that can contain or store programming for use by or in connection with an instruction execution system, apparatus, or device. 
         [0042]    The instructions can also be propagated within any transport medium for use by or in connection with an instruction execution system, apparatus, or device, such as those describe d above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a transport medium can be any medium that can communicate, propagate or transport programming for use by or in connection with an instruction execution system, apparatus, or device. The transport readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic or infrared wired or wireless propagation medium. 
         [0043]    One skilled in the relevant art will recognize that many possible modifications and combinations of the disclosed embodiments can be used, while still employing the same basic underlying mechanisms and methodologies. The foregoing description, for purposes of explanation, has been written with references to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations can be possible in view of the above teachings. The embodiments were chosen and described to explain the principles of the disclosure and their practical applications, and to enable others skilled in the art to best utilize the disclosure and various embodiments with various modifications as suited to the particular use contemplated. 
         [0044]    Further, while this specification contains m any specifics, these should not be construed as limitations on the scope of what is being claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Technology Category: 3