Intel’s Total Memory Encryption

I can understand the questions as an academic one.
As for a practical one... I can't understand why anybody wants to slow down their memory access by encryption.
 
I can understand encrypted disks for the above reason, but RAM?
DRAM is uninitialized until it is powered up and loaded.

I don't have a dog in this event, but still trying to understand the "why" of encrypted RAM.
 
bgavin said:
DRAM is uninitialized until it is powered up and loaded.
Click to expand...
Yes, and once the system is running it might contain interesting things like encryption keys or passwords. Sure, those keys should be used then wiped from memory but there's a window of opportunity here. You can actually yank out the memory and read its contents in another system. Freezing the module apparently extends the time it takes for the tiny capacitors to discharge.
 
bgavin said:
but still trying to understand the "why" of encrypted RAM.
Click to expand...
IMHO it's mostly the same as with "self encrypting disks"/"encryption at rest" that doesn't even need any interaction at boot:
Just another checkbox on some PHBs buzzword-list that can be sold at a premium.


Besides, IMHO it shouldn't be the job of the memory to fix insecure software that doesn't clean up behind it and leaves unencrypted data lying around in RAM after being terminated...
 
I have to ask again... DRAM is volatile, so how is there data lying around?
This seems like a solution in search of a problem.
Again, no dog in this fight.. just scratching my head over "why"
 
Answer #4 answered the "why" ... there may still be ways to access the data. How practical they are or how real the risk is - are the next questions. But no-one answering the OP yet!
 
I do not think that feature has anything to do with the operating system. It is encrypted by the bios/internal minix system. You can read the ram to some extent until it is completely discharged (and it takes some minutes (I think up to 2-3). I would say not needed for most users. But with very confidential data it might be necessary (intiligence services).
 
"Intel TME capability does not require any operating system or system-software enabling."

As far as I understand that article, this feature is kinda independent of the OS.. idk
 
See the "multi key" part? This is going to be fun. Guess who will have a backup key? If the crypto is worth anything, that is. But then it won't be fast enough. I hope it is a checkbox, but I fear it smells of spooks and the riaa.
 
getopt said:
Where do you see a "multi key" part in the text of the link OP did give us for reading?
Click to expand...

Intel TME-MK technology is built on top of Intel TME. It enables the use of multiple encryption keys, allowing selection of one encryption key per memory page using the processor page tables. Encryption keys are programmed into each memory controller. The same set of keys is available to all entities on the system with access to that memory (all cores, direct memory access [DMA] engines, and more). [...]

[...]


The Intel TME-MK technology maintains a key table (internal to the CPU and invisible to the software) that stores key and encryption information that's associated with each KeyID. Each KeyID may be configured for:


Encryption using a software-specified key

Encryption using a hardware-generated key

No encryption (memory is plain text)

Encryption using a default platform TME Key
Click to expand...


sounds like "everyone and everything can use and acces keys however they want" - what could possibly go wrong?
 
sko
I tried to search for "multi key" in the browser and got for unknown reason no hit. Then I asked. Then I doubt and searched again and found it. Then I edited my post. Then I read your answer. That was not performing well. Sorry.
 
bgavin said:
I have to ask again... DRAM is volatile, so how is there data lying around?
This seems like a solution in search of a problem.
Again, no dog in this fight.. just scratching my head over "why"
Click to expand...
What do you mean by "volatile"?

You might think that if you power the computer down, or reboot it, the DRAM is guaranteed to be gone. That's simply not the case. Let's start with reboot: It does not have to wipe the RAM. A very small part of the RAM will have to be overwritten by the boat loader (to start whatever OS it needs to load), but the rest of RAM can be recovered after a boot. I don't know whether standard BIOSes of today clear memory (I doubt it). In a previous job, we had our BIOS modified by the BIOS vendor to intentionally leave as much of the RAM unmolested; after a reboot we would then search all of memory for cached data, check whether the cache was still valid (that's what networks and multiple copies are for), and then most likely use most of the cache. Much faster than reloading the cache from disk.

Next question: Power cycling. About 30 or 40 years ago, when DRAM first came on the scene (as opposed to SRAM), everyone knew that DRAM has to be regularly refreshed, otherwise it will lose its content. Early microprocessors (think 6502 and Z80) used to refresh roughly at the CPU frequency (a MHz or two); with the memory chips commonly used back then, that meant that each row of memory cells was refreshed at multiple kHz, which lead to the tribal knowledge that if you wait longer than a ms to refresh, your data is gone.

Today, that's completely untrue. The last time I measured this was about 15 years ago: you can turn all accesses and refreshes off and cut power to the DRAM for roughly a second, and the rate of memory errors will still be very very low (in the 10^-large number range)). At 10 seconds, you better verify all data structures in memory (with CRCs or checksums), since the error rate will be low but measurable. As larshenrikoern said, you can still get stuff after a minute (although 15 years ago, there wasn't much left then). As SirDice said, the effect is temperature dependent.

sko said:
IMHO it's mostly the same as with "self encrypting disks"/"encryption at rest" that doesn't even need any interaction at boot
Click to expand...
All the self encrypting disks I know do need to be given a key to unlock, but perhaps not immediately at boot, or perhaps in a fashion that's not visible to the user. One example are IBM/Lenovo laptops, where the boot password is used to unlock the (IBM- or Hitachi-made) disk drive; if you remove the drive from the laptop, you find that it is unreadable. I think modern Apple laptops work the same way (not sure, haven't taken one apart in ages). Similarly, in many large cloud environments, the boot loader knows how to contact a key server over the network, and uses the secure hardware identity (from the trusted platform module) as authentication. So by the time the users even show up, all the required interaction has taken place. And again, if the disk is physically separated from the server (like found in the dumpster), it is useless.

Besides, IMHO it shouldn't be the job of the memory to fix insecure software that doesn't clean up behind it and leaves unencrypted data lying around in RAM after being terminated...
Click to expand...
Pretty much any software had to decrypt the data it works on for a short period, to process or copy it. So there is always a window of vulnerability. Good software design can minimize or obscure that window, but eliminating it is really hard.
 
SRAM and DRAM are both classified as volatile.
Volatile is defined as losing their content when power is removed.

en.wikipedia.org

Static random-access memory - Wikipedia

en.wikipedia.org en.wikipedia.org

A warm reboot does not drop power, so memory contents remain as they were prior to the restart.

The ECC and DDR types found in most servers are volatile.
It seems to me the Intel process is a solution in search of a problem.
 
bgavin said:
It seems to me the Intel process is a solution in search of a problem.
Click to expand...
Yes and no. They failed to ensure memory separation due to their shortcuts in speculative execution. Now they try for "no matter that someone reads your memory when he shouldn't. It's encrypted!". Untill someone gets to the keys.
 
Crivens said:
Yes and no. They failed to ensure memory separation due to their shortcuts in speculative execution.
Click to expand...
In their defense: Most other high-end microprocessors with multiple execution units also have speculative execution, and they probably have similar vulnerabilities when the side effects of speculative execution become visible (some were actually found to be vulnerable). Intel got most of the flak for it, because they are big, and everyone hates them (for reasonable reasons, they don't act like nice guys). It's the saying about Caesar's wife: given their position, Intel should have been better.

Untill someone gets to the keys.
Click to expand...
That's not that easy. In production environments, keys are disposable, generated on the fly, and time-bombed (they typically are valid for hours). That moves the problem to the key management infrastructure, which contains master keys. But that thing can be protected very well: remember the steel wire cages in data centers containing the Kerberos servers. In today's large server environments, the key servers are highly segregated, secured, and monitored.
 
ralphbsz you describe a secure server place, I see a single point of failure.

A key once escaped is gone. It is not important if it was lawful or not. It will end up in the wrong hands, and I count the TLAs in this set here.

People will feel safer with this, and they will skip on the required operational safety. Or they will turn it off because of speed.

Another problem that crossed my mind yesterday, what will this do with shared memory? It is only worth anything if the keys differ between processes. No shared memory, and no debugging. Yay!

Or you generate the keys on the fly and pass them to the MMU for each page, that will be fun to implement and get correct. I can not see a scenario where this is working out well.
 
You must log in or register to reply here.
Back
Top