27

I want to store some data in a variable (and I know variables are stored in memory). Does that data in memory get encrypted? Also, is it possible for software to be able to read the variable names stored in memory and be able to actually extract the data from it?

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
Tom F
  • 807
  • 6
  • 20
  • 2
    No, not encrypted by default. What are you actually trying to do? – Mitch Wheat Jun 14 '11 at 00:15
  • 1
    Memory stores exactly what you put into it, so if you don't encrypt it it isn't encrypted, and if you can read it most likely someone else can. Not posting this as an answer, because I'm voting to close the question. :) – Ken White Jun 14 '11 at 00:18
  • 15
    This isn't a dumb question, it's quite a good one actually! – Marlon Jun 14 '11 at 01:08

6 Answers6

30

Memory is not encrypted on any platform I know about. It would be of limited value anyway, because the processor must, in general, operate on plaintext data, so the data must be in plaintext on the machine somewhere.

Instead, modern operating systems (and most historical ones) use memory protection to allow only certain processes access to certain memory pages. Every memory page comes with read, write, and (sometimes) execute permissions. The operating system kernel is in charge of handling those permissions on context switch to grant or deny access to memory pages per-process as needed.

Saltzer and Schroeder's 1975 paper The Protection of Information in Computer Systems describe a mechanism using segments, rather than pages, but the principle has remained unchanged for decades.

Typically, any process-owned memory page is readable by a process with high-enough privilege; the OS kernel certainly can modify any page of memory, and it can choose to delegate that privilege to user processes too. The ptrace(2) system call on Linux provides a debugger-backdoor that can be used to implement read-only memory inspection systems such as strace(1) or ltrace(1) or gdb(1), or memory-modification systems such as gdb(1) and ptrace-based sandbox environments.

Or, a core file can be dumped, under certain situations (see core(5) and setrlimit(2) manpages), containing the contents of the process's memory. This is one reason why it is important to clear memory of important data before release.

I was part of a team that worked on encrypting pointers (non-PTO link) in running programs. The overhead was amazing, and the number of corner cases was even more astonishing. Using these techniques for common programs is probably not practical, though I could imagine a restricted environment where encrypted memory or control structures is a feasible approach. (Though probably other techniques would be more appropriate.)

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • 3
    re *the processor must, in general, operate on plaintext data, so the data must be in plaintext on the machine somewhere* - there are systems where that "somewhere" is just inside the processor, and there's an encryptor/decryptor embedded in it so that the actual data is encrypted anywhere outside the processor. In this case it's much harder to hack it without actual physical contact (having malicious software is not enough). – littleadv Jun 14 '11 at 00:37
  • @littleadv, good point; I have wanted a [Cryptographic CoProcessor board](http://www-03.ibm.com/security/cryptocards/) for years, but have no real _need_ for one. Hehe. – sarnold Jun 14 '11 at 00:40
  • +1, that's an exemplary answer, with great insights, great references, and experience to speak of (even though I can't open your `encrypting pointers` link). – zneak Jun 14 '11 at 03:02
  • @zneak, thanks; I changed the link to the USPTO.gov site and added a link to a third-party website that is far friendlier _and_ looks better. But cluttered with ads. I guess you just can't win. :) – sarnold Jun 14 '11 at 03:18
  • Thanks for the in depth answer! Really cleared some things up for me. For people that are wondering, I'm storing 'Captcha' data in memory, basically for a registration process people will have to enter a Captcha code (like any forum registration), that's why I was wondering this :-) – Tom F Jun 14 '11 at 13:32
  • @Thomas, you did pique my curiosity with what you were building.. :) Thanks for letting me know. :) – sarnold Jun 14 '11 at 23:42
  • 2
    A good example of platform where memory is encrypted and yet performance is quite acceptable is the Xbox 360. Contents of RAM are decrypted when read to the CPU cache, and re-encrypted when written back. IIRC the crypt. logic is embedded next to the cache itself. http://www.youtube.com/watch?v=uxjpmc8ZIxM&feature=player_detailpage#t=1009s – danielkza Jun 27 '11 at 12:09
  • @Danielkza, wow, that's astonishing! Any idea how they key the algorithm? Any idea how they re-key the algorithm? (Many ciphers have extremely expensive key setup phases.) Thanks! – sarnold Jun 27 '11 at 22:12
  • Good insights! I am also trying to protect a very few amount of memory data (the passphrase of a private key typed by the users). Since the process is a long running process (a daemon, in fact), I would like to protect that memory as best, even from root... is that possible without specialized hardware (I don't care for overhead)? From your answers I guess, that the answer is no, but we never know ^^ – Vincent Pazeller Jan 30 '15 at 10:16
  • @VincentPazeller, the `memset_s` function is supposed to help zero memory and prevent the optimizer from discarding the call entirely; see http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html for more information. – sarnold Feb 11 '15 at 23:41
  • @sarnold, Actually, I don't want to zero the memory because the key is used by the daemon when it receives a request (i.e. any time). That is, the key must be available and cannot be zero-ed. Zero-ing the memory is useful when you just need the sensitive data at a given time and don't need it after (if I understood well). – Vincent Pazeller Feb 13 '15 at 00:17
  • @VincentPazeller, ahh, I see. There's not much you can do, sorry. – sarnold Feb 13 '15 at 19:30
12

Okay, so I want to store some data in a variable (which, I know, variables are stored in memory) - does that data in memory get encrypted?

NO

Also, is it possible for software to be able to read the variable names stored in memory and be able to actually extract the data from it?

Names or values?

For values:

You mean a different program, not yours, to access it and read it? Yes, it's possible, depending on OS it may be tricky or trickier, but doable.

For names: Depends on how you build your software - if you leave debug info in it - it's very easy to do that.

littleadv
  • 20,100
  • 2
  • 36
  • 50
  • Actually, any debugger is able to do it. – zneak Jun 14 '11 at 00:20
  • I'm assuming he's asking about malicious software, not a debugger run by the user himself with the appropriate permissions:-) – littleadv Jun 14 '11 at 00:21
  • Of course, debuggers are best used to, well, debug code :) Still, they're relatively user-friendly tools to inspect memory. If you find a security flaw that lets you run programs with elevated privileges (or just as somebody else), they're probably the easiest (external) entry point into other programs. That was mostly meant to point out that there are well-known programs that let you read and write to another process's memory. – zneak Jun 14 '11 at 02:00
5

No. Memory is not typically not encrypted.

Memory stores data that you write into it. At somepoint, memory will contain the plain-text version of your data, and this is sometimes used as a way to exploit systems.

That said, once an attacker has physical access to your machines, it's very difficult to secure them.

There are some language specific features that attempt to address this, such as C# SecureString , but even these have their limitations.

Alan
  • 45,915
  • 17
  • 113
  • 134
5

Does that data in memory get encrypted?

Usually no. I say "usually" only because you could conceivably make an operating system or hardware that does encrypt memory. So really, no.

Is it possible for software to be able to read the variable names stored in memory and be able to actually extract the data from it?

Depends. With code in an interpreted language like PHP variable names are kept in memory somewhere, so conceivably it's possible. With compiled code like (like C++), it could be compiled with debug information (and then a debugger would be able to see variable names and extract their values), or it could be compiled without it and then the variable names are lost.

Also, it's very easy to write a program that reads arbitrary memory addresses, but it's much harder to figure out what the bytes you read mean.

trutheality
  • 23,114
  • 6
  • 54
  • 68
0

sarnold's answer on memory protection is correct. However, there are attacks that can circumvent many forms of memory protection. These include covert channels, residual information in newly allocated memory, DMA-based attacks like firewire, attacking a trusted device w/ access, attacking kernel mode software, physical attacks, etc. A combination of encryption and integrity checking of memory can help with some of these attacks.

If you're interested in encrypted memory, here's a few projects for you to look into.

MIT AEGIS Processor

SecureCore architecture

SecureME architecture

Air Force's FPGA-based HAVEN system

Tamper proof, crypto coprocessors might be used for some of this. They're just not as general purpose.

An alternative getting popular again is putting the whole platform, OS and all, in managed or type safe code. This allows the type system to do most of memory protection for you. Examples include Scheme48, SPIN, JX, and Verve operating systems and software.

Nick P
  • 1,477
  • 1
  • 11
  • 14
0

There are solutions emerging that can encrypt memory on standard x86 microprocessors from physical compromise (cold boot attacks, someone walking away with Non-volatile Dual Inline Memory Modules (NVDIMMs) containing persistent data, plugging in malicious I/O cards that do Direct Memory Access (DMA) attacks, etc).

One approach is to use a high assurance hypervisor that runs in the CPU Last Level Cache (L3 cache). Inside the CPU is clear text, outside the CPU is encrypted memory.

Note that you will still need to protect against privileged users and patch your applications (all the stuff you already do), but the new technology does protect data-in-use against physical compromise.

Todd
  • 1
  • 1