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
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.
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.
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.)
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.
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.
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.