Integrity self-check of secure code within a VM environment using native VM code

A method of running an application in a process virtual machine (PVM) on a computing device using a dynamically-linked module (DLM) with an integrity self-check feature is provided. The DLM is written in PVM-native bytecode, and the PVM is configured to execute applications stored as PVM-native bytecode within a single code file associated with that application. The method includes (a) dynamically linking the application to the DLM by loading the PVM-native bytecode of the DLM from a resource file separate from the single code file of the application, (b) performing the integrity self-check feature on the DLM to ensure the integrity of the PVM-native bytecode of the DLM, and (c) in response to the DLM passing the integrity self-check, calling functions of the DLM from within the application. Embodiments directed to analogous computer program products and apparatuses are also provided.

BACKGROUND

In order to qualify for certain government standards, cryptographic software must satisfy certain conditions. One such condition, such as imposed by FIPS140-2(which has been promulgated by the Federal Government on May 25, 2011 and revised on Dec. 3, 2012), is that the cryptographic algorithms self-validate to ensure that they have not been corrupted. The process of certifying that such software meets the FIPS140-2standard can be expensive, often costing on the order of $100,000.

One conventional approach has satisfied the FIPS140-2conditions for cryptographic software on mobile devices running the ANDROID operating system (OS) by implementing the self-validating cryptographic algorithms in machine code to run on the mobile devices, the machine code being called as an external library by an ANDROID OS application the ANDROID OS application running within a DALVIK virtual machine (VM).

Another conventional approach has satisfied the FIPS140-2conditions for cryptographic software on mobile devices running the ANDROID operating system by implementing the self-validating cryptographic algorithms on a specialized hardware module. A similar hardware-based approach has been used by KoolSpan, Inc. of Bethesda Md. in its TrustChip® mobile encryption engine products (see http://www(dot)koolspan(dot)com/products/mobile-encryption-engine(dot)html and linked pages).

SUMMARY

Unfortunately, the above-described conventional approaches to satisfying FIPS140-2validation on a mobile device suffer from deficiencies. Implementing the self-validating cryptographic algorithms in machine code libraries rather than as native DALVIK VM code is less than ideal for at least two reasons. First, non-DALVIK VM code is unprotected and may crash the mobile device, while, in contrast, the DALVIK VM environment is protected against such crashes. Therefore, certain users are wary of operating non-DALVIK VM code on their devices for security and safety reasons. Second, non-DALVIK VM code is platform-dependent, while, in contrast, DALVIK VM bytecode is portable, capable of running on any DALVIK virtual machine. Thus, in order to operate on a wide variety of ANDROID operating system (OS) mobile devices, the cryptographic software must be shipped with the machine code libraries compiled for each different hardware platform, or customized distributions must be made based on the platform requirements. This requires complexity in distribution and installation as well as code bloat. Furthermore, since the self-validation must be done on the code just before execution, each separate compiled version must be separately FIPS140-2certified, multiplying the certification costs to several hundred thousand dollars, depending on the number of supported hardware platforms.

Implementing the self-validating cryptographic algorithms in hardware is also deficient because users typically do not want to carry extra hardware around with them, nor do manufacturers want to install extra hardware in their devices for only limited applications.

It would be desirable to implement self-validating cryptographic libraries in compliance with the FIPS140-2standard in native DALVIK VM code that is not susceptible to crash the system and that does not require re-compilation and re-certification for a multitude of hardware platforms. Thus, in contrast, the present disclosure is directed to techniques for using FIPS140-2certified self-validating cryptographic libraries implemented in portable form within the DALVIK virtual machine.

In one embodiment, a method of running an application in a process virtual machine (PVM) on a computing device using a dynamically-linked module (DLM) with an integrity self-check feature is provided. The DLM is written in PVM-native bytecode, and the PVM is configured to execute applications stored as PVM-native bytecode within a single code file associated with that application. The method includes (a) dynamically linking the application to the DLM by loading the PVM-native bytecode of the DLM from a resource file separate from the single code file of the application, (b) performing the integrity self-check feature on the DLM to ensure the integrity of the PVM-native bytecode of the DLM, and (c) in response to the DLM passing the integrity self-check, calling functions of the DLM from within the application. Embodiments directed to analogous computer program products and apparatuses are also provided.

DETAILED DESCRIPTION

Techniques are provided herein for using FIPS140-2certified self-validating cryptographic libraries implemented in portable form within the DALVIK virtual machine (VM) as well as additional generalized embodiments.

FIG. 1depicts a system30for use in connection with various embodiments. System30includes a computing device32. Computing device32may be for example, a personal computer, a desktop computer, a workstation computer, a server computer, an enterprise server computer, a laptop computer, a mobile computer, a portable computing device, a tablet computing device, a smart phone, etc. In a typical embodiment, computing device32is a mobile computing device running any version (either presently released or substantially backwards-compatible with released versions) of the ANDROID operating system, produced by Google, Inc. of Mountain View, Calif.

Computing device32includes a processor34. Processor34may be, for example, a central processing unit, a microprocessor, a collection of multiple microprocessors, a digital signal processor, a field-programmable gate array, a collection of circuits configured to perform various operations, or another similar device or set of devices configured to perform operations. Computing device32also includes a cellular and network interface36for connecting to network38. Network38may be, for example, a wide area network (WAN), a local area network (LAN), a point-to-point connection, a cellular data network, etc.

Computing device32also includes a user interface (UI)40, including circuitry, for connecting to one or more UI devices42in order to receive and transmit information to a user. UI devices42may include, for example, a display monitor, a touch-sensitive display device, a keyboard, a keypad, a mouse, a tracking pad, a tracking ball, a microphone, a speaker, other similar devices, or some combination thereof. In some embodiments, one or more of the UI devices42may be embedded within the computing device itself, such as, for example, a touch-sensitive display screen embedded within a cellular smart phone or tablet. The circuitry of UI40may include, for example, a graphics card, a graphics accelerator, a sound card, a serial port, a parallel port, an analog to digital converter, a digital to analog converter, or similar devices having similar functionality for connecting to UI devices42.

Computing device32also includes storage44and memory46. Storage44is a form of non-volatile memory for storing files and data. Storage44may be, for example, a hard disk drive, a floppy diskette drive, a CD-ROM drive, a DVD drive, a Blu-ray drive, a solid-state disk drive, magnetic storage, optical storage, flash memory, some combination thereof, or another similar device or set of devices configured to store application programs and or application data. Memory46may include, for example, system memory, cache memory, volatile memory, random access memory, some combination thereof, or another similar device or set of devices configured to store running software and or data.

Storage44stores a main application executable code file, such as, for example, main application DALVIK VM executable (DEX) code file50. Main application DEX code file50includes a set of class definitions52and a loader class definition54, making up a main application.

The class definitions52,54are in a portable bytecode format, the portable bytecode format being designed to operate on a process virtual machine (PVM), which, as is well-known in the art, is a piece of application software that runs on the computing device32(on top of a separate host operating system, such as the ANDROID operating system) and that provides a virtual execution environment for the portable bytecode, the portable bytecode containing instructions which are executed by the PVM.

It should be understood that, within this Description, any time a piece of software is described as executing, running, operating, or performing a method, function, step, operation, etc., the method, function, step, or operation is actually performed by the processor34while executing code of the software stored in memory46.

In one embodiment, used hereinafter as the primary example, the PVM is a DALVIK VM, and the class definitions52,54are written in portable DALVIK VM bytecode. Class definitions52,54may have been compiled from JAVA language source code or from any other kind of code which can be compiled and/or converted into DALVIK VM bytecode format, such as, for example, the GROOVY, SCALA, PYTHON, and C computer languages, etc. The portable bytecode is typically machine-readable code, which is code which does not actually contain alphanumeric characters, but rather binary codes that represent instructions. Machine-readable code is not directly understandable to most humans—rather a human will typically only be able to understand the machine-readable code once it has been converted into an assembly-like format.

Storage44also stores native DALVIK VM libraries56, which may be accessed by any DALVIK VM application, as well as a resource directory58associated with the main application. If several DALVIK VM applications are installed on the computing device32, each such application may have its own dedicated resource directory, although, in some embodiments, all applications may share a single resource directory. Resource directory58stores a dynamically-linked module (DLM) resource file, such as DLM JAR file59. DLM JAR file59may be a compound file storing multiple files. One file stored within the DLM JAR file59is DLM code file60, which stores DALVIK VM code to implement a DLM to be invoked by the main application. DLM JAR file59also stores a message authentication code (MAC)61. DLM code file60is a self-validating file, which is configured to self-validate with reference to the MAC61before executing. Further details with respect to the DLM JAR file59and the self-validation process are provided below, in connection withFIG. 3.

Storage44may also store additional components (not depicted), such as an operating system, PVM code, other application programs (both native and PVM-based), application data, user data, etc.

Memory46stores a PVM, such as DALVIK VM64during execution, as well as other executing and loaded code such as the operating system, drivers, and other applications and data (not depicted). DALVIK VM64includes a DALVIK VM environment66for the execution of loaded DALVIK VM bytecode, such as main application classes72and loader class74(loaded from the set of class definitions52and the loader class definition54, respectively) of a main application70. Main application70is a DALVIK VM application, configured to make calls to a DLM80(encoded by DLM code file60), also loaded in memory46. DLM80includes an integrity self-check function81as well as one or more functions82configured to encode core functionality of the DLM80. In one embodiment, the core functionality related to cryptographic operations. Memory46also stores native DALVIK VM library classes86.

In operation, once the main application70has been loaded into memory46as main application classes72and loader class74, loader class74attempts to load DLM80to allow the main application to call functions within the DLM80. Loader class74first loads the contents of the DLM code file60, and then calls an initialization function of the DLM80, which is configured to activate the DLM80for execution once it is able to verify that the MAC61encodes an expected value, indicating that the code within the DLM code file60has not been corrupted. Further detail is provided below in connection withFIGS. 2-4.

Storage44may include a computer program product. The computer program product stores a computer program within a tangible non-transitory computer-readable storage medium. The computer program, when executed by processor34(and stored in memory46), is configured to cause the processor34to perform a method (seeFIG. 4, below) according to various embodiments.

FIG. 2depicts an example main application DEX code file50according to various embodiments. Main application DEX code file50includes a set of class definitions52and a loader class definition54, encoding main application70. The set of class definitions52includes a main application class definition152. The loader class definition54and main application class definition152are depicted in further detail in the figure with example JAVA language code fragments. It should be understood that the loader class definition54and main application class definition152are actually stored within storage44as portable DEX machine code, and not JAVA language source code. However, since the DEX machine code is typically generated from JAVA language source code (by means of a JAVA language compiler and a DALVIK VM code converter), it is helpful to view the original source code which was used to encode the end-product DEX machine code.

Loader class definition54includes a declaration153of a JAVA language Interface called CryptoModule as well as a class definition154of a class called CryptoModuleLoader. CryptoModuleLoader154defines a LoadDLM function160. LoadDLM function160includes a section of code162which is configured to load the DLM code file60from storage44and extract a DALVIK VM class called CryptoModuleImpl therefrom using reflection. It should be noted that the code162as depicted in the figure actually extracts the class directly from the DLM JAR File59for simplicity of presentation—in an actual implementation, additional code is used to open the JAR and extract the class from the DLM code File60instead. The extracted class is cast as a CryptoModule Interface153object, since it is expected that the CryptoModuleImpl class defined within the DLM code file60implements the CryptoModule Interface153. Casting to a locally-declared Interface allows calls to the extracted class to be made without using reflection, which serves to optimize, since reflection is slow. LoadDLM function160also includes a section of code164which is configured to open the DLM JAR File59for reading, and a section of code166which is configured to call a function to extract the MAC61from the DLM JAR File59. LoadDLM function160also includes a section of code168which is configured to call an initialization function, InitModule, of the newly-loaded CryptoModule Interface153object (since the CryptoModule Interface153declaration included a declaration of the InitModule function). In this function call to InitModule, the LoadDLM function160passes the MAC61and an object encoding an open file stream for accessing the DLM JAR file59to the InitModule function. That allows the InitModule function to self-validate with reference to the MAC61and the file stream.

Main application class definition152defines a main function, which is the main body of code executed by the main application70upon loading. The main function first includes a section of code170which is configured to invoke the CryptoModuleLoader class154and its LoadDLM function160in order to load and initialize the DLM80. Once DLM80is loaded, if it is properly validated, the main function is able to make function calls172to particular core functions82of the DLM. It should be understood that, although these core functions82are defined within the DLM code file60and not within the main application DEX code file50, the main application70is able to make these function calls170because the core functions82are declared within the CryptoModule Interface153declaration.

FIG. 3depicts an example DLM JAR file59according to various embodiments. DLM JAR file59includes DLM code file60and a manifest200which stores MAC61. Manifest200may also store additional information, such as metadata about the DLM code file60and any other files stored within DLM JAR file59. MAC61encodes a unique signature which may be used to validate the integrity of the DLM code file60. In some embodiments, MAC61is a symmetric signature, while in other embodiments, MAC61is an asymmetric signature. In some embodiments, MAC61is a cryptographic hash, while in other embodiments, MAC61is a non-cryptographic hash, fingerprint, or checksum. MAC61should have the property that any small change to the contents of DLM code file60should result in a different value for MAC61.

The contents of DLM code file60are depicted in further detail in the figure with example JAVA language code fragments. It should be understood that the contents of DLM code file60are actually stored within storage44as portable DEX machine code, and not JAVA language source code. However, since the DEX machine code is typically generated from JAVA language source code (by means of a JAVA language compiler and a DALVIK VM code converter), it is helpful to view the original source code which was used to encode the end-product DEX machine code.

DLM code file60includes a definition of the CryptoModuleImpl class253, which implements the CryptoModule Interface153declared within the loader class definition54. CryptoModuleImpl class253defines the InitModule function268which was also declared within the CryptoModule Interface153. Upon receiving a file stream reference and a MAC value61, the InitModule function268is configured to perform an integrity self-check by calling CheckIntegrity function81. CheckIntegrity function81reads the entirety of the DLM code file60from storage44, computes a signature (or, in some embodiments, a hash, fingerprint, or checksum) of the DLM code file60, and compares the value to the MAC value61received. If the comparison of the values indicates that the file has not been altered (according to techniques well-understood in the art), then the CheckIntegrity function81returns TRUE, otherwise, FALSE. The reason why the InitModule function268is passed the file stream reference (which, it should be understood, may be any kind of object capable of reading from a file, such as an IOStream, a File Reader, etc.), is because the DALVIK VM does not allow code to read the file in which it is itself stored. Thus, the DLM80, which is stored in the DLM code file60, cannot directly access the code of the DLM code file60from storage44. Rather, the main application70accesses the code of the DLM code file60and passes the file object to the DLM80.

If the CheckIntegrity function81returns TRUE, then the InitModule function268is configured to perform various actions to enable the DLM80for future function calls. Otherwise, the InitModule function268deactivates the DLM80such that it is not available to be called. CryptoModuleImpl class253also defines the various core functions82which may be called by code172in the main application class152.

FIG. 4depicts an example method300according to various embodiments. Method300is performed by computing device32. In step310, the PVM (e.g., DALVIK VM64) dynamically links the main application70to the DLM80by loading the bytecode of the DLM80from a resource file (e.g., DLM JAR file59) separate from the single code file (e.g., main application DEX code file50) of the main application70. Main application70is run within the PVM environment (e.g., DALVIK VM environment66), typically upon being loaded by a user via the UI42. When the main application70is run, classes72may be executed to perform core operations of the main application. At some point during execution, code contained within the DLM80may be needed to be executed in conjunction with the main application classes72. In one embodiment, upon the main application70first loading, loader class74may be invoked to load DLM80from the DLM JAR file59. In other embodiments, the loader class74may only be invoked to perform that function upon code from the main application classes72actually having a need to invoke core classes82of the DLM80within the context of operation. In any case, once the LoadDLM function160of the loader class74is invoked, it causes the DLM code file60to be extracted from DLM JAR file59and loaded as a class.

In step320, the DLM80performs an integrity self-check to ensure the integrity of the code contained within DLM code file60before it is invoked. First, the LoadDLM function160of the loader class74executes code segments164,166to set up the DLM JAR file59as a file object and to read the MAC61. Then, the LoadDLM function160executes code segment168to call the InitModule function268of the DLM80. DLM80is then able to run the InitModule function268to perform the integrity self-check by reading the contents of the DLM code file60from the file object, hashing the contents, and comparing with the MAC61. It should be understood that, although, as described, the MAC61is passed to the InitModule function268, in some embodiments, the InitModule function268does not receive the MAC61as an argument, but, rather, the InitModule function268reads the MAC61from DLM JAR file59via the file object.

In step330, which is performed only if the self-check is successful, the main application70is able to call core classes82of the DLM80within the context of operation in order to carry out various cryptographic operations.

In step340, if the self-check is unsuccessful, an error is returned, and the main application70is not able to call the core classes82.

In some embodiments, a second application distinct from main application70may also be configured to invoke the same DLM80either from the same DLM JAR file59in the resource directory58or from a different copy of the same DLM JAR file59in a different resource directory. In either case, the contents of the DLM JAR files59are identical. Thus, only one FIPS140-2certification is needed even though two or more applications may make use of the code therein, saving many thousands of dollars in certification costs.

Thus, techniques have been provided to allow for a self-validating external native VM code module (DLM80) to be called by main application80in the context of operation by a VM64that is configured to execute code from a single code file50and to prohibit code from directly accessing itself in storage44.

For example, although embodiments have been described in which the PVM is the DALVIK virtual machine and the portable bytecode is DALVIK VM bytecode, it should be understood that this is by way of example only. In other embodiments, other PVMs that execute other forms of bytecode may be used instead, provided that the PVM is configured to either execute native code only from within a single file or to prevent executing code from accessing itself in storage.

As an additional example, it should be understood that, although various embodiments have been described in the context of FIPS140-2validation and certification, other forms of integrity self-check validation are also encompassed within the invention.

As an additional example, it should be understood that, although various embodiments have been described as being methods, computer programs embodying these methods may also be included. Thus, one embodiment includes a tangible computer-readable medium (such as, for example, a hard disk, a floppy disk, an optical disk, computer memory, flash memory, etc.) programmed with instructions, which, when performed by a computer or a set of computers, cause one or more of the methods described in various embodiments to be performed. Another embodiment includes a computer which is programmed to perform one or more of the methods described in various embodiments.

Furthermore, it should be understood that all embodiments which have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded or are impossible.

Finally, nothing in this Specification shall be construed as an admission of any sort. Even if a technique, method, apparatus, or other concept is specifically labeled as “prior art” or as “conventional,” Applicants make no admission that such technique, method, apparatus, or other concept is actually prior art under 35 U.S.C. §102, such determination being a legal determination that depends upon many factors, not all of which are known to Applicants at this time.