Encryption and the Key in RAM

[beginner99]

Well not sure if this is highly technical or not compeltely stupid but I had a few thoughts about Encryption and as it is getting more and more important and widley used.
So called experts claim stuff like AES-256 is secure at least for now. I don't want to disagree but the weakness always is the key.

So bascially if I decrypt something I need to have the key in memory. And hence if it is in memory it is accessible. So a trojan/virus/malware could just "analyze" your ram to find the key and any encryption will be useless. Ok, not like very clear how to recognize a key, but theoretically it's there in "plain text".

What am I missing?

 

[Evadman]

What am I missing?

Memory protection and segmentation.

 

[Mark R]

Memory protection protects a program's memory from other program's - but not from the OS or from drivers.

Using the debugging capabilities of the OS, it would be possible to get access to a program's memory and analyse it. This technique has been used to extract the DVD and blu-ray encryption keys from media player software. However, installing and using OS debugging features requires installation of the debugger software (which needs privilege elevation) and your login must have permission to use a debugger. So, a Trojan couldn't install itself as a debugger without you accepting the UAC request. Similarly, if this is a work PC, then it's easy enough to lock down employee's logins so they can't install or use a debugger.

In order to get round this problem of protecting he MPAA's keys MS has designed Vista and win 7 in such a way that windows can perform the decryption of DRMed movies itself, using a special 'debugger proof' module - if you boot windows with OS debugging active, the video decryption modules are blocked from loading.

 

[Cogman]

Memory protection protects a program's memory from other program's - but not from the OS or from drivers.

Using the debugging capabilities of the OS, it would be possible to get access to a program's memory and analyse it. This technique has been used to extract the DVD and blu-ray encryption keys from media player software. However, installing and using OS debugging features requires installation of the debugger software (which needs privilege elevation) and your login must have permission to use a debugger. So, a Trojan couldn't install itself as a debugger without you accepting the UAC request. Similarly, if this is a work PC, then it's easy enough to lock down employee's logins so they can't install or use a debugger.

In order to get round this problem of protecting he MPAA's keys MS has designed Vista and win 7 in such a way that windows can perform the decryption of DRMed movies itself, using a special 'debugger proof' module - if you boot windows with OS debugging active, the video decryption modules are blocked from loading.

Honestly though, if the system is somehow compromised then any sort of protection is useless. Even if the system prevented the virus from looking directly at memory, it would not prevent it from just modifying the executable in general, or even just simply logging keys when the executable comes online.

 

[beginner99]

Honestly though, if the system is somehow compromised then any sort of protection is useless. Even if the system prevented the virus from looking directly at memory, it would not prevent it from just modifying the executable in general, or even just simply logging keys when the executable comes online.

Yeah keylogger is even simpler than accessing memory.

But can't a virus "simulate" to belong to a programm or attach itself to it and hence get access to memory?

This is actually why I had the idea, because of hacks in online-games. As far as I read these programms "injected" (that's how they called it) an additonal dll into your game. For me this sounds like that dll then has access to the memory of that software. But as you can see I don't really have a clue.

 

[Modelworks]

To truly keep a key private you have to use hardware support. Software will always have a vulnerability. If you place the decryption processor inside the cpu then there is nothing exposed to intercept. This is what most of the SOC designs do now.

The SOC has a unique internal key that can be device specific so each device has a different private key based on serial number or something else. Any program data is sent to the cipher module before the main cpu gets access to it , decrypted , then sent to the main cpu. Since there is no user program access to that path until it gets to the main cpu the path is protected. The data is encrypted all the way from storage until it is run on the cpu.

The memory used by the decryption processor is not readable by software since the entire routine is transparent to the code running on the main cpu. As far as the cpu running the OS or programs is concerned the data has always been in its unencrypted form. Multiple program authentication can be done by using public keys unique to the user. Someone could get my public key but it would not work on their hardware because the private key inside the cipher module would not match. The only place the data would be unencrypted is the physical bus wires from the cipher module to the cpu, being they both are in the same physical chip, nobody without millions to spend on equipment could access the data. The reason this was not done until the past year or two is because cipher modules were not fast enough to do the decryption in real time.

The next advance is placing the cipher module in the physical ram chips. Where even the contents between the cpu and ram will be protected adding another layer.

 

[Ben90]

The weakest link is the user. If they install some exec that contains a Ring0 virus, it will be able to access the memory.

 

[beginner99]

To truly keep a key private you have to use hardware support. Software will always have a vulnerability. If you place the decryption processor inside the cpu then there is nothing exposed to intercept. This is what most of the SOC designs do now.

Is that thingy in the Arrandales/Clarkdales such a decryption processor?

 

[Modelworks]

Is that thingy in the Arrandales/Clarkdales such a decryption processor?

Sort of but not in the same way as dedicated devices implement it. Intel added instructions that can be used to run the AES calculations in hardware but that only addresses the speed of how the keys are generated and not the physical security of them .

A decryption processor contains its own ram and cpu that does the functions transparent to the OS. To run a program , the OS sends the cpu the encrypted program data , the core inside the cpu decodes it, runs the code like a normal cpu, encrypts the data for anything sent back to the OS and then returns control to the OS.

Any program attempting to read from another programs memory would need the proper key to that area of memory otherwise it would read that location as garbage.

This is what IBM says on it

A word sized encryption layer may be added between the microprocessor and the L1 cache. It would encrypt everything before it leaves the layer for the cache and decrypt it anything returns to the processor. Alternately, an encryption layer could be added between the L1 and L2 caches. It would encrypt cache blocks as the ascended from the L1 cache to the L2 and it would decrypt cache blocks as they descended from L2 to the L1 cache. Or the crypto layer could be placed between the L2 cache and main memory. It would encrypt cache blocks before being sent on to the memory controller and decrypt them before they came back in and filled a cache line.