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:34 ADT
Simon R Knight (srk@tcp.co.uk)
Tue, 16 Jun 1998 19:05:09 0000
I am a new subscriber to the CodherPlunks list, and note with interest
the references to the "Twofish" block cipher, which is quite new to
me.
Last night I visited Bruce Schneier's web site and downloaded some of
the info there. The paper "Cryptoanalytic Attacks on Pseudorandom
Number Generators", is particularly interesting , as I am presently
considering how I might best implement a PRNG within my own software.
As this paper highlights the importance - among other things - of
keeping the secret state of a PRNG unknown to an attacker, I find the
question naturally arises as to how security might be provided for
such a value - or indeed any sensitive data like keys etc - in in a
modern Windows PC.
In the "Windows For Workgroups 3.11" .pif editor under:
Help/Advanced Options, there are descriptions of options where an
application can be locked in memory; either conventional, expanded,
or extended. The helpfile states that an application locked in memory
will not be swapped to a hard-disk, but will remain in physical
memory (i.e. RAM). These options are interesting in that they appear
to indicate that locking data in physical memory is possible, and yet
I have also read statements that indicate quite the opposite ? If it
is genuinely possible to "lock" an application - or (more
specifically) sensitive data - in physical memory, then this would
obviate the risk of such sensitive data being swapped to disk, which
is clearly very desireable.
In my Win16 API helpfile, there is a function called "Global Lock"
which appears to deal with some kind of memory locking, although
exactly what form of lock is established is far from clear.
The helpfile has this to say:
"Locked memory will not be moved or discarded unless the memory
object is reallocated by the GlobalReAlloc function. The object
remains locked in memory until its lock count is decreased to zero."
... however under the corresponding "GlobalUnlock" function, the
helpfile says:
"The GlobalUnlock function unlocks the given global memory object.
This function has no effect on fixed memory."
If the "GlobalUnlock" function has no effect on fixed memory, then it
follows that the "GlobalLock" has no effect upon fixed memory either,
which begs the question; what is being locked ?
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.
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
immediately bypassed by real-world operating systems ? It would
(for e.g.) seem a trivial task for an operating system (or program)
to watch for any 128 byte memory allocation on Windows local heap, or
a 128 byte sub-allocation of a block on the global heap, and copy any
values therein. A 128 byte value associated with MD5, or a 160
byte value associated with SHA (for e.g.), must appear rather
distinctive. The issue of the computer memory security is made all
the more interesting because little appears to have been written
about it. Is there a case (for e.g.) for allocating less distinct
amounts of memory during cryptographic processes, and padding the
extra bytes with decoy data ? A brute force attack against large keys
is already regarded as computationally impractical, and compared to
advanced surveilance and cryptanalysis of a target, compromising the
operating sytem(s) at root, would appear infinitely simpler. With
Windows sytems distributed with their own TCP/IP stacks and
Dial-Up-Networking, the operating system itself is probably one of
the most advanced surveilance sytem a government could wish for.
When you consider that Microsoft's operating system is running on
computers in Russia, the midde East, China, and many other places, it
would be very useful for these operating systems to answer their
modems when no one's around. Where cryptographic levels of security
are involved, it would seem prudent to assume that the fundemental
security of operating systems like Microsoft's, have already been
compromized by a variety agencies, and that advanced cryptographic
attacks are only necessary against hardware based systems.
I would be most interested in any feedback on the above and/or any
pointers to where I might find a detailed analysis of this kind.
Thanks,
Simon R Knight
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:34 ADT