What Is a Code Cocoon™?
AMULETs ™ contain within them definitions for both passive and active defenses of its digital asset client.
Passive defenses refer to where the Certitude framework seeks out environmental information on behalf of the AMULET ™ (so that the AMULET ™ can determine whether access to the protected digital asset will be permitted) but does not alter that environment (we also refer to these as “AMULET ™ Framework Services”).
An AMULET ™’s active defenses, on the other hand, change the environment (file or operating system) to create the ideal conditions for safe access to the digital asset – these active defenses are known as “Code Cocoons ™”.
Definitions of both passive and active defenses can exist in the same AMULET ™, and when they do, all of the conditions of the passive definitions must be satisfied before the active defense are mounted, and of course any defined active defenses must be negotiated before access to the protected digital asset is finally granted.
Issues Addressed by a Code Cocoon ™
File System and Memory Issues
In the Windows and other operating system, executable files, dynamic link libraries, and other critical files associated with an application are generally stored on the disk file system in the same form in which they will appear in memory once executed. When stored in compressed or “zipped” form, upon access they are decompressed to a temporary file on disk, which is then identical to the image that will appear in memory at runtime.
Even when encrypted by the operating system, the encryption keys and methods are often the same across all of the files in a volume, or even across all the files in the entire system. And even when encrypted via the notoriously-weak, NSA-enabling encryption deployed by most operating systems, there is no way for the operating system to tell if the file that was encrypted is the same version of the file the other components of the application are expecting, unless the application renders these checks itself.
All of these limitations allow hackers opportunities to interfere with or corrupt an application. In the case where there is no encryption, hackers can identify the location of the runtime image of a file in memory by comparing the file’s disk image to blocks of memory. In the case of an encrypted source file, the hacker needs merely to set an operating system event upon loading of the disk file, and find the memory that was altered immediately after the load – this memory location will contain the same file after decryption.
Most protection schemes for modern computers assume the hacker will be coming from outside via a network connection, and attempt to protect local resources by defending those network connections. In the case of someone wanting to extract intellectual property appropriately from a piece of software, they will not be attacking the system from an external connection. They will instead buy and install a single legitimate copy of the software on their computer, hacking it using other software installed on the same machine – that is, from inside. Or, a hacker may use a virus via the Internet which installs a virus on the computer, indirectly attaining internal access, or software hidden on a thumb drive, or social engineering to gain internal access to a computer.
Once inside, all of the techniques for comparing what is on the hard drive with what is in memory become available to the hacker. With respect to the theft of intellectual property, particularly from an employer, the thief is most often and employee or other trusted individual who already has full access to all the resources, including the stolen digital asset, on the computer from which the item was taken.
How They Work
A Code Cocoon ™ is an invention which, in addition to other things, prevents or makes difficult the comparisons between what is on the hard drive in one environment and what is in memory in another, keeping even momentarily-exposed intellectual property in a different environment than the one which is native to the host computer.
A Code Cocoon ™ is available in one of two forms:
- RAM drive Code Cocoons ™ – a faster version which offers significantly enhanced security over what the operating system can provide by obfuscating the physical storage form of the digital asset
- Virtual machine Code Cocoons ™ – a somewhat slower form that offers even more security by creating a completely different environment around the digital asset
Both forms of Code Cocoons ™ verify that source files are the exact versions and contents expected as established by the user at AMULET ™ configuration through SHA2 hashes of the original source files in memory and/or on disk.
RAM Drive Code Cocoons ™
The RAM drive version uses a modified version of a random access memory (RAM) drive to provide the additional layer of security. Upon initial startup of the host operating system, the AMULET ™ system manager creates a RAM drive in memory from reserved memory data segments assigned to its own process thread, but does not publish the existence of the RAM drive to the operating system or assign a drive letter to it. The low-level means of accessing the RAM drive (via data segment offset and load address) is kept private to the AMULET ™ system image manager.
The AMULET ™ system image manager loads all registered Code Cocoon ™ files from their original locations on the hard drive onto the hidden RAM drive, interlacing and enciphering (or re-enciphering) the file contents in a unique pattern as they are loaded, so that no file load event can be tied to a specific memory location or vice versa, or byte sequence from the original hard disk file can be linked to a byte sequence on the RAM drive.
Neither the newly enciphered-in-memory image of the file now on the RAM drive or the events associated with RAM drive file activity are visible to the operating system (or therefore, users). When in the course of normal use of a an application which contains an AMULET ™ describing a Code Cocoon ™ a Code-Cocoon ™-protected file needs to be accessed, the AMULET ™ system image manager knows through pre-registry to load that file in enciphered interlaced form from the hidden RAM drive rather than from the file’s original location on the hard drive.
Virtual Machine Code Cocoons ™
The second form of the Code Cocoon ™ carries the same idea a step further. Again, a hidden RAM drive is mounted by the AMULET ™ system image manager at operating system startup. However, instead of pre-registered Code- Cocoon ™-protected files being loaded from hard drive onto the hidden RAM drive, a single-file virtual machine with its own enciphered file system is loaded onto the RAM drive. The information that would normally be published to the host operating system about the existence of the virtual machine is instead not published and kept within the confines of the AMULET ™ manager. Now, pre-registered Code-Cocoon ™-protected files are interlaced and enciphered (or re-enciphered) onto the virtual machine’s enciphered virtual “hard” drive (now effectually itself a RAM drive).
Code-Cocoon ™-protected components using this most advanced form of Code Cocoon ™ must be configured by the user during AMULET ™ setup to accept input files containing any required parameters for passing, and to output a file at a known location on the virtual machine. The Code-Cocoon ™-protected component will be executed in process threads mounted by the virtual machine, and just before execution input files stored on the host hidden RAM drive will be transferred to the virtual machine.
After completion of execution, output files generated by the execution will be transferred from the virtual machine back to the hidden host RAM drive. In this manner, every aspect of the Code-Cocoon™ protected component and its execution will be completely concealed and protected during runtime.
The virtual machine code cocoon in combination with the passive environmental conditions evaluation supplied by the AMULET ™ provides a nearly insurmountable level of security, as much as can be attained in software
Future Application of Code Cocoons™
Because virtual machines are available for most host operating systems in a variety of other operating systems (as well as that of the host) and are not required to use the same operating system as their host, the Code Cocoon ™ effectively allows any operating system to run code for any other operating system for which a virtual machine is available.
So, a Windows application running on a Windows operating system can easily and very securely (through a Code Cocoon ™) run code written for any one of a number of Linux operating systems (including Android), for example. A MacIntosh computer running OSX Snow Leopard could run, again through a Code Cocoon ™, an application originally written for and on a Windows Surface tablet. An Apple iPhone (iOS) can run an Android application, and vice versa.
The possibilities are endless – effectually it means that a vendor can write code once in the language and operating system of their choice, and run that code as part of another application running in any host device in any operating system for which a virtual machine is available.