Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:33 ADT
Marcus Watts (mdw@umich.edu)
Tue, 16 Jun 98 16:26:17 -0400
You wrote:
> From: "Simon R Knight" <srk@tcp.co.uk>
> To: CodherPlunks@toad.com
> Date: Tue, 16 Jun 1998 19:05:09 0000
> Subject: Locking physical memory (RAM) under Windows
...
> I have asked a couple of programming friends, and I get a different
> answer from each of them. One says that such memory will be locked
> and immoveable, and another says that it will be both locked and
> moveable. I get the impression that although such memory is "locked",
> that it is actually some kind of virtual lock.
I think a better term here would be "pinned". A "lock" can mean many
things - another common use for the word "lock" is to "lock" a data
structure so that only one control thread can use it. Another way to
phrase this is that the lock is used to "serialize" access to the
data structure. The real world analogy would be an airplane restroom
that can only be used by one person at a time - the door lock and
occupied sign are used to "serialize" access to the toilet, and
other would-be users of the toilet are "blocked", and may queue up
in the aisle waiting for access.
"Pinned" memory, on the other hand, could be used either by one
thread at a time, or by many at once. All that "pinned" means is
that it's given a fixed physical location in memory, and stays
there. One common use for "pinned" memory is for DMA I/O. It
would be very bad if the memory were moved while a DMA disk read
were in progress. At best, the data wouldn't end up in the
right place. At worst, if something else were given the use of
that memory, very bad things could happen. Pinned memory is
also often used for interrupts - for instance, the memory used
for an interrupt handler is usually pinned. This is because a
page fault in an interrupt handler is usually at least undesirable.
>
> If possible, it would be inifinitely preferable to *reliably* lock a
> small amount of physical memory to hold sensitive data, than to
> explain to software users, how their virtual memory bypasses
> security, unless it is turned off, or set to a fixed length and wiped
> afterwards; neither of which is ideal. I can of course wipe areas of
> memory associated with variables that contained sensitive data, but
> unless such data is allocated only fleetingly, there would seem every
> possibility that the memory pointed to is no longer the physical
> memory that was originally written to.
>
> With much of the emphasis on the mathematical security of
> cryptographic algorithms, to what degree is such security
...
You need to decide what kind of theat you are worried about, then
design your application to be proof against that. The reason
that people worry about mathematical security is because it's
the one piece that shared between two different systems, and
hence can't be "improved". Every practical system will have
its weakpoint. In order to prove the security of that system,
you have to identify and upgrade the weak point. If the math
is the weak point, you can't fix it without breaking interoperability.
Modern high performance computing systems are, and are not, a problem.
The good news is that most modern machines feature hardware memory
protection, and operating systems are available that exploit those
features. Properly used, such systems can be highly secure. The
bad news is that these modern systems also feature many high performance
features which are both "complicated" and could "leak information", and
that some of the most popular operating systems available have terrible
security built into them.
Regarding "128 byte memory allocations". You have obviously not done
much programming. Programmers don't generally allocate separate
small chuncks of 128 byte memory to hold MD5 keys. They are much more
likely to stash such things on the local stack, to use random
globals for these, or to allocate larger chunks of memory that might
hold file information, a user's name, and an incidental hash.
I very much doubt MicroSoft has programmed their OS to answer the modem
when nobody is around. If I were going to suspect MicroSoft was designing
back doors to leak information, I'd be much more suspicious of the fact
that MicroSoft Word stores all sorts of "incidental" garbage when you save
your document. Even there, though, no, I don't think the NSA did that,
I think it was purely that it was "easier" and "faster" to program word
to act that way. Again, this is something you learn out of programming:
it is faster to allocate a smaller number of larger chunks of memory than
lots of smaller ones, and it is faster (but also more bug-prone) not to
pre-clear memory if you're going to immediately store data into that memory.
Regarding threats against computers, here is a partial list of
threats to worry about:
(1) someone might steal the computer, and gain permament
possession of the thing.
(2) someone might "borrow" the computer, and either
copy the data on the computer, change the
data that is stored on the computer, or
physically alter the computer.
(3) someone might run an active "attack" against the
computer through a network while it's running.
(4) someone might "passively" listen to the data being sent
through the network to or from the computer.
(5) someone might attack the person who owns the
computer, and use large heavy black rubber sticks.
(6) someone might seduce the person's secretary and
steal all the passwords that are hidden under the
typewriter table.
All of these threats are possible, and all have been used in the
past with success. It is silly to invest too much effort in increasing
security against one form of attack, if another form of attack is left
wide open. The bad guys are obviously not going to play fair.
It is interesting to look at how banks, which have had a long
history of having to worry about these sorts of problems, deal with them.
Banks tend to be a lot more keen on audit trails, alarms, and hiring
reliable employees, than they actually worry about physical security.
The point with a bank is not to make it impossible, but to ensure that
it can be detected, and something actively done, when it happens.
Getting back to the computer for a moment, the first and best thing
you can do is to run an OS that is relatively immune to computer viruses.
That means, unfortunately, no MacOS, no MicroSoft Word, and no Windows.
One of the many unix derivatives can be good, if set up correctly.
Doing this, and worrying about physical security will put you way
ahead of the game. Depending on your application, you might then want
to worry about the other points above. None of these will make you immune
to the NSA. If you are worried about the NSA, and you're using a laptop
with windows, you are, um, "out of it".
-Marcus Watts
UM ITD PD&D Umich Systems Group
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:33 ADT