Tamper resistant memory protection

Various mechanisms are disclosed for protecting the security of memory in a computing environment. A security layer can have an encryption layer and a hashing layer that can dynamically encrypt and then dynamically hash sensitive information, as it is being loaded to dynamic memory of a computing device. For example, a memory unit that can correspond to a memory page can be processed by the security layer, and header data, code, and protect-worthy data can be secured, while other non-sensitive data can be left alone. Once such information is secured and stored in dynamic memory, it can be accessed at a later time by a processor and unencrypted and hash checked. Then, it can be loaded back onto the dynamic memory, thereby preventing direct memory access attacks.

COPYRIGHT NOTICE AND PERMISSION

A portion of the disclosure of this document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice shall apply to this document: Copyright® 2008 Microsoft Corp.

FIELD OF TECHNOLOGY

The presently disclosed subject matter relates to the field of computing, and more particularly, to fields such as media content, although this is merely an exemplary and non-limiting field.

BACKGROUND

Data memory in game consoles, as well as open computing platforms (such as personal computers), is usually susceptible to hacking attacks that can either fully compromise the security system of a given device, or minimally cause specific applications to misbehave, such as granting their users undeserved privileges. Such attacks can include: a game cheat device that modifies memory to give a gamer unlimited ammunition in a shooter game, thus allowing the gamer to attain better achievements than had the hack not occurred; or, a device that changes the in-memory value of a pre-paid cell phone, thus allowing a user to increase the available minutes. Hence, what is needed is tamper resistant memory protection mechanisms to prevent such hacks and any other hacks prevalent in the field.

SUMMARY OF THE INVENTION

Various mechanisms are disclosed for protecting the security of memory in a computing environment. A security layer can have an encryption layer and a hashing layer that can dynamically encrypt and then dynamically hash sensitive information, as it is being loaded from a first memory to a second memory, where the second memory can comprise dynamic runtime memory or persistent storage memory. For example, a memory unit that can correspond to a memory page can be processed by the security layer, and header data, code, and protect-worthy data can be secured, while other non-sensitive data can be left alone. Once such information is secured and stored in the second memory, it can be accessed at a later time and loaded back onto the first memory (which may include on-chip local cache memory). This process may entail checking for hash integrity and then decrypting the sensitive information, while at the same time simply loading other non-sensitive information.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Overview

The presently disclosed subject matter is designed to prevent illicit outside read and/or write access to data memory by encrypting (and/or signing) data page content as it is written into memory. Moreover, it is designed to decrypt such content as it is read out of memory by legitimate application calls. Thus, attempts to physically read protected data can result in garbled returned data, and any attempt to modify memory can result in a system failure. The presently disclosed subject matter envisions a system that is transparent to the application layer and can be optionally enabled for specific application data in order to avoid potential performance degradations.

Aspects of Tamper Resistant Memory Protection

FIG. 1illustrates that in the prior art, all of memory was protected, instead of only selected portions of sensitive memory. Thus, a computing device160having a memory165would typically have all code and data encrypted (and/or hashed—not shown). If the memory165comprised of different dynamic memories, such as memory A180and memory B, that memory165would be encrypted regardless of the protection warranted by the code and/or data. By way of example and not limitation, inFIG. 1, memory165could be runtime dynamic memory such as random access memory (RAM). Alternatively, in other aspects of the presently disclosed subject matter, it could be persistent memory such as hard disk device.

In the scenario where memory A180and memory B185stand for different locations of one single memory165(or even two different memories altogether), in the prior art both locations would be encrypted167even if memory A180contained sensitive code and/or data but memory B185contained non-sensitive code and/or data. This resulted in unnecessary wastage of computing processing resources, since non-sensitive code and/or data did not need to be protected. Moreover, another downside of security systems where all memory is encrypted is an increase in difficulty of interoperating with peripheral devices. Peripheral devices including DVD drives, hard disks and USB input devices are capable of directly writing to memory. However, if this memory has a requirement of being properly encrypted, all peripheral devices that could access this memory would have be knowledgeable of the encryption method and any required cryptographic secrets. Still furthermore, on a finer scale of granularity, in the prior art if a memory page was accessed, and such a page contained both sensitive and non-sensitive code and/or data, the entire page was encrypted (thus, in another scenario, memory A180and memory B185can stand for different memory pages in the memory165). This again resulted in processing resource wastage.

Thus, in contrast toFIG. 1,FIG. 2represents an improvement over the prior art where selected portions of memory are protected, that is, encrypted and/or hashed. In direct contrast toFIG. 1, inFIG. 2only memory A180is encrypted and memory B185is not encrypted. In the aforementioned scenario where memory A180is a first page of memory, and memory B185is a second page of memory, only the former page would be encrypted167.

Furthermore, on an even finer scale of granularity, the shown memory165can stand for a single memory page, and memory A180and memory B185can be different portions of the same memory page165. It should be noted, that the memory165can also stand for a selected amount of bits or bytes of memory and does not have to correspond to a traditional notion of a memory page, as those of skill in the art would understand that concept. Thus, any given page could be accessed by a computing system, and only sensitive portions of that page could be encrypted. The rest of the code and/or data could be left alone, and any computing resources could be accorded towards other tasks.

FIG. 3shows the different levels of granularity355that were discussed above. For example, given a memory page340, this memory page340could comprise of at least four types of information: (1) header data305; (2) code310; (3) sensitive data315; and (4) other non-sensitive data320. All this information could correspond to a memory unit A300, which in turn could correspond to a memory page340.

In an alternative aspect of the presently disclosed subject matter, memory unit A300could correspond to a selected number of bits345or bytes347. For example, this selected number could vary, such as being 8 bytes for one memory unit, 1024 bytes for another memory unit, or 4096 bytes for still another memory unit. Alternatively, all memory units could be of a fixed, uniform size, depending on the specific implementation.

Any given memory165could comprise of a plurality of such memory units, such as memory unit A300, memory unit B304and memory unit N306. Each memory unit could have all of its protect-worthy information encrypted or individually encrypted. As is shown inFIG. 3, the header data305could be encrypted325, the code310could be encrypted, and the sensitive data could be encrypted335. Furthermore, an encryption350or the encryptions325,330,335could be performed.

As is shown inFIG. 4, this scenario also could hold analogously true for hashing such information. Thus, the header data305could be hashed400, the code310could be hashed405, and the sensitive data315could be hashed. Moreover, a hash415of hashes400,405,410could be performed for added information integrity (provided that hashed information could be protected by a reliable cryptographic signature). The encryption discussed with respect toFIG. 3could be performed in combination with the hashing shown inFIG. 4. Encryption could ensure that information is not readable, and hashing could ensure that information is not writable.

Next,FIG. 5illustrates a security layer530that could be responsible for encryption505and/or hashing of selected information510. The security layer530could be a system or computer readable medium bearing computer executable instructions for managing encryption505and/or hashing510(alternatively, it could be practiced as a method for encryption505and/or hashing510). On the other hand, the security layer530could also be used for decryption and for checking hashes.

When information is read from, for example, a hard disk, it could be decrypted and hashes could be checked for integrity, and then such information could be loaded onto a console random access memory. Alternatively, when information is stored from the console random access memory onto the hard disk, such information could be dynamically and selectively encrypted and hashed, thus ensuring that any sensitive data (and/or header data and/or code) is securely stored on the hard disk. Of course, it is contemplated herein that such encryption/decryption and hashing/checking could occur between any kind of memories on any kind of computing devices, whether flash memory or on-chip memory, or general computing devices or closed computing devices.

Turning now toFIG. 5, a memory unit300can be accessed from some remote memory500(such as a persistent memory, as exemplified by hard drives, jump drives, etc.). Information in the memory unit300can be originally encrypted and hashed525, and then decrypted and hash-checked and stored onto local computing device memory570(such as local on-chip memory or some intermediate memory inside a device). The security layer530can dynamically decrypt550the relevant information in the memory unit300and dynamically check for hash integrity555via a decryption layer505and a hashing layer510, respectively. Such decryption and checking can be performed on-the-fly on a memory unit-by-memory unit basis and then loaded onto local memory570as cleartext565(i.e. unencrypted and understandable information). Other non-sensitive information can be simply loaded without having the security layer530process such non-sensitive information.

Once the relevant information is locally loaded570, it can be read and written, and then loaded onto dynamic memory500, such as random access memory (RAM). In such a scenario, any important header data, code, and sensitive information can be dynamically encrypted and hashed on a memory unit-by-memory unit basis and stored by a module560into the dynamic memory500(a loader can contain the store/access module560). The result is that important information can be secured525while also allowing the unobstructed access/storing of non-sensitive information that does not need to be protected. In short, in this aspect of the presently disclose subject matter, sensitive information can be protected525not only on persistent memory devices515, but also on dynamic memory devices500. Such protection address direct memory access (DMA) hacking, which may occur when information is loaded and stored on dynamic memory.

Further to this point,FIG. 6illustrates one exemplary and non-limiting aspect of the presently disclosed subject matter where information is protected in various memory contexts and yet readable and writeable in other memory contexts. In the context of persistent storage memory515and dynamic memory500(such as RAM), sensitive information is encrypted and/or hashed. While in local memory570, such information may be unencrypted and hash checked. InFIG. 6, the local memory570is shown being separated from the dynamic memory500. Local memory570can on-chip memory (e.g. L1cache) or memory in between a processor and RAM (e.g. L2or L3cache). Of course, the local memory570may still be some other memory storage device, not part of the processor600and not part of the dynamic memory500. InFIG. 5, the local memory570is shown as either subsisting on the processor600or outside the processor600—yet, being separate from the dynamic memory500. In short, the architecture shown inFIGS. 5 and 6allows for sensitive information to be protected while it is being stored during operation on dynamic memory500.

FIG. 7shows how the security mechanisms mentioned above protect important information, and the consequences of tampering with protected information. For example, malicious entity A700(which can be a person, a computer program, and so on), can attempt to read710the encrypted and/or hashed memory unit725. However, the result of such a read710is that the data becomes garbled and undecipherable720. Similarly, if a malicious entity B705attempts to write715to the encrypted and/or hashed memory unit725, the result can be a system failure725—for instance, when a security system discovers a mismatch in hash values. (It should be noted that Entity A700and Entity B705can be the same entity, different entities, entities of different kind, and so on). In this latter scenario, the entire computing system, whether it be a console, a personal computer, any kind of mobile device, and so on, can fail upon such a write attempt to sensitive data.

Furthermore, in the scenario where a write occurs to memory that is encrypted but not hashed, such a write may succeed, but since a malicious entity making the write is not aware of encryption key values, garbled data will end up being written. Thus, in another aspect of the presently disclosed subject matter, the sensitive information is encrypted with hidden keys associated with the computing device but not accessible to any malicious entity.

Finally,FIG. 8illustrates a block diagram flow chart summarizing various aspects of dynamically encrypting and/or hashing sensitive memory units. For example, the presently disclosed subject matter can not only be instantiated as a system, but it can also be stored in a computer readable medium storing thereon computer executable instructions or it can be practiced as a method. For example, at block800, a computer readable medium can have at least one instruction configured to access a persistent storage device. For example, the instructions can be copied from the medium onto console memory.

Next, at block805, the computer readable medium can have at least one instruction configured to identify in the memory header data, code, and sensitive data. As was mentioned, not all data on the exemplary external hard drive has to be sensitive. Only certain information, such as game points, scores, and so on may be sensitive. Other data, such as avatar and game subject matter (cars, characters, and so on) configuration may not be sensitive, and hence not of concern to protect.

In one aspect of the presently disclosed subject matter, information about which code and/or data is sensitive and the level of protection given to various ranges thereof in memory can be stored within the data itself. One potential location for this data can be a single master information header included with the data. Another potential location can be a unit-specific information header that describes a level of protection granted to the range following it.

At block810, shown is at least one instruction configured to dynamically check a hash of the memory header data, code, and sensitive data, and then at block815, at least one instruction configured to dynamically decrypt the memory header data, code, and sensitive data. The order of such checking and decrypting may be reversed, depending on the need. Moreover, such dynamic checking and decrypting (and hashing and encrypting) of memory units can be performed by the encryption/decryption505and hashing layers510. Once the aforementioned information is unencrypted and checked, it can be stored on local memory, as discussed with respect toFIG. 6.

At block820, once the relevant information has been checked and decrypted, at least one instruction can be configured to store the header data, code, sensitive data and any other associated non-sensitive data in random access memory. Regarding the non-sensitive data (or more generally, information), it can also be stored on a console along with the checked and decrypted sensitive data. Moreover, the mentioned memory is exemplary and non-limiting, since any on or off processor memory can be used to store such information (including any internal console hard disk memory). The way in which such information will be stored will depending on the computing device in question, possibly varying for game consoles, personal computers, and mobile devices (such as cell phones).

At block825, at least one instruction is configured to dynamically encrypt the memory header data, code, and sensitive data as it is loaded onto a runtime dynamic memory. Such information may persist in the dynamic memory during the operation of a computing device, and it may be accessed by a processor (in the process of being access and loaded on processor local memory, such information in the meantime may be unencrypted and/or checked). Once the processor is done processing the information, it can once again be encrypted and/or hashed and stored in the dynamic memory for later processing. Finally, at block840, any information designated for persistent storage, whether sensitive or non-sensitive, can be stored in persistent storage so that when the computing device is turned off, it will not be lost.

It should be noted that in performing a dynamic hash at block830, additional integrity measures can be taken, such as performing a hash of hashes, as is shown at block835. Once all the desired security measures are taken (e.g. encryption and integrity hashing), more instructions can be configured to store the memory header data, code, sensitive data and any other associated non-sensitive data in various memories. By dynamically providing memory unit-by-memory unit encryption and hashing on the console, selected sensitive information can be protected in non-traditional contexts, such as dynamic memory (which in the past has been vulnerable to hacker attacks).

Exemplary Computing Devices and Networks for Tamper Resistant Memory Protection Mechanisms

The above discussed computing devices, whether native or remote, can be embodied as gaming consoles, music players, personal computers, and other such devices having different, similar, or the same platforms. Contemplated herein are also hand-held devices, laptops, cell phones, and so on. Referring toFIG. 9, a block diagram shows an exemplary multimedia console that can be used in conjunction with the various aspects of the tamper resistant memory protection system discussed above. This console, which includes a game oriented console or a PC, may comprise, for example, digital audio processing functionality. Specifically, inFIG. 10, a multimedia console100is shown, with a central processing unit (CPU)101having a level1(L1) cache102, a level2(L2) cache104, and a flash ROM (Read-only Memory)106. The level1cache102and level2cache104can temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput. The flash ROM106may store executable code that is loaded during an initial phase of a boot process when the multimedia console100is powered. Alternatively, the executable code that is loaded during the initial boot phase can be stored in a flash memory device (not shown). Further, ROM106can be located separately from the CPU101. These memory devices can cache parts or the entirety of the above mentioned applications, programs, applets, managed code, and so on. Moreover, these memory devices can store sensitive and non-sensitive information on a memory unit-by-memory unit basis, as was discussed above.

A graphics processing unit (GPU)108and a video encoder/video codec (coder/decoder)114can form a video processing pipeline for high speed and high resolution graphics processing. Data can be carried from the graphics processing unit108to the video encoder/video codec114via a bus. The video processing pipeline can output data to an A/V (audio/video) port140for transmission to a television or other display. A memory controller110can be connected to the GPU108and CPU101to facilitate processor access to various types of memory112, such as, but not limited to, a RAM (Random Access Memory). Thus, various types of information, whether sensitive or not, or even parts of various types of information, can be stored in the various types of memories discussed above, depending on the need.

The multimedia console100can include an I/O controller120, a system management controller122, an audio processing unit123, a network interface controller124, a first USB host controller126, a second USB controller128and a front panel I/O subassembly130that can be preferably implemented on a module118. The USB controllers126and128can serve as hosts for peripheral controllers142(1)-142(2), a wireless adapter148, and an external memory unit146(e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). Moreover, the network interface124and/or wireless adapter148can provide access to a network (e.g., the Internet, home network, etc.) and may be any of a wide variety of various wired or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.

System memory143can be provided to store application data that is loaded during the boot process. A media drive144can be provided and can comprise a DVD/CD drive, hard drive, or other removable media drive, etc. The media drive144can be internal or external to the multimedia console100. Application data can be accessed via the media drive144for execution, playback, etc. by the multimedia console100. The media drive144can be connected to the I/O controller120via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 1394).

The system management controller122can provide a variety of service functions to assure the availability of the multimedia console100. The audio processing unit123and an audio codec132can form a corresponding audio processing pipeline with high fidelity, 3D, surround, and stereo audio processing according to aspects of the presently disclosed subject matter above. Audio data can be carried between the audio processing unit123and the audio codec126via a communication link. The audio processing pipeline can output data to the A/V port140for reproduction by an external audio player or device having audio capabilities.

The front panel I/O subassembly130can support the functionality of the power button150and the eject button152, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console100. A system power supply module136can provide power to the components of the multimedia console100. A fan138can cool the circuitry within the multimedia console100.

The CPU101, GPU108, memory controller110, and various other components within the multimedia console100can be interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures.

When the multimedia console100is powered on or rebooted, application data can be loaded from the system memory143into memory112and/or caches102,104and executed on the CPU101. Such application data can include some of the online derived data. The application may also present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console100. In operation, applications and/or other media contained within the media drive144can be launched or played from the media drive144to provide additional functionalities to the multimedia console100.

The multimedia console100may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the multimedia console100may allow one or more users to interact with the system, watch movies, listen to music, and the like. However, with the integration of broadband connectivity made available through the network interface124or the wireless adapter148, the multimedia console100may further be operated as a participant in a larger network community of computing devices. As such a participant, it may interact with computing devices, whether PCs or servers, and receive information that may be eventually stored.

Next,FIG. 10illustrates an exemplary networking environment for subject matter discussed with reference toFIGS. 1-9. The above discussed gaming console100can correspond to any one of the aforementioned computing devices, or it can be distributed over such devices. It can interact with various other objects155and storage devices158via a communications network/bus154, where such objects and devices can correspond to other computing devices (whether hardware, firmware, or software). The cross-platform applications can communicate in peer-to-peer networks or client-server based networks, depending on the implementation. Thus, sensitive information can not only be stored on the exemplary external hard disks that are attached to game consoles, but rather such information can be remotely located and access over any kind of network.

In the case of program code execution on programmable computers, the computing device may generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the creation and/or implementation of domain-specific programming models aspects of the present invention, e.g., through the use of a data processing application programming interface (API) or the like, are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined.

Finally, while the present disclosure has been described in connection with a plurality of exemplary aspects, as illustrated in the various figures and discussed above, it is understood that other similar aspects may be used or modifications and additions may be made to the described aspects for performing the same function of the present disclosure without deviating therefrom. For example, in various aspects of the disclosure, methods, systems, and computer readable media were described configured for providing tamper resistant memory protection mechanisms. However, other equivalent mechanisms to these described aspects are also contemplated by the teachings herein. Therefore, the present disclosure should not be limited to any single aspect, but rather construed in breadth and scope in accordance with the appended claims.