how-to block ads
|
jansson_mark
Markus Jansson
Premium
join:2001-08-05
Finland
4 edits |  Idea for steganographic filesystem for Windows
I hate to start discussion on this subject on two forums, but incase folks at Truecrypt dont want to implement it...
quote:
http://forums.truecrypt.org/viewtopic.php?t=6212
OK, to make the idea / implementation REALLY simple, why not just simply add TC option to, when creating TC container, to create the TC container as file, as device or, as superhidden container starting from sector X? And when decrypting, option to instead of mounting a container or device, to mount a sector X (that user would supply)? TC could simply have some kind of check for the disk to ensure that no files exist on the sectors where the container is to be created and to protect those sectors from Windows when the container has been mounted.
(Quick note to clarify incase you dont read all three my postings in that forum:
- If the free space on the hdd where the superhidden container will be created is wiped with random data, you cannot spot the superhidden container from the other random data that is in that hdd:s free space.
- If user is too lame to remember the sector number of the superhidden container, the header data could simply be stored at the last sector(s) of the hdd where TC could automatically look for it.)
What do you think about it? Could it be done? What positive/negative effects it would have? Any comments are most welcome. 
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | |
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
 ·Verizon Online DSL
| The primary object with any encryption system is to avoid presenting any information to those who might attempt hostile access... and that information includes the mere existence of encrypted info, the location/size of such, the technique used for the encryption, details of the language/content-type/data-structure of the plaintext, etc, etc.
In a computer environment, that implies both the encryption scheme used and the specific product created should not only hide their existence from casual (or even determined) browsing, they must also hide their existence from those who would attempt to expertly search for them on the basis of known/published rules, protocols, or patterns for laying down encrypted documents - regardless of how those embedment technique might work. Right off, that means the software used to create and embed the encryption must, itself, not ordinarily reside on the same system as the encrypted material, else a direct vector is created to cue the analyst onto how best to seek out encrypted products related to that software. And the encrypted material must not self-betray its existence. An amazing number of digitally-encrypted documents have been speedily cracked, simply by recognizing the kind of software that created them and focusing on the encryption attributes unique to such software... and that revelation came from simply viewing the encryption software resident on the same computer or by studying header information in an obviously encrypted file.
The foundational problem I see with your creative concept of using the hard drive as a container is that there must be something hosted on the system that prevents Windows or any other OS from over-writing any sectors/segments/clusters used by the encryption scheme. And that, unfortunately, provides a vector identifying that the drive may be encrypted and what the encryption techniques may be. Once that is known, all the analysts' horsepower can be leveraged into cracking that specific system. Another potential problem is that many kinds of disk cleanup programs (defragmentation, repair, etc) move data around with abandon... unless use of these were blocked or governed by the encryption program's "something", havoc would result with the enciphered text which would render the plaintext unrecoverable. And, of course, existence of that "something" would again point directly toward the presence of encrypted material and the technique used to create it.
Part of the difficulty resides squarely in the nature of what one is attempting to encrypt. The smaller the plaintext core, the better and safer things will be. The larger the plaintext body or number of files being encrypted, the harder it is to hide the presence of the encipherment and the harder it is to prevent cracking once detected. In general, if one is attempting to encrypt folders full of numerous files, the results of whatever is used will be measurably less secure than similarly encrypting a short segment of plaintext using the same techniques.
Some of the very best steganographic encryption for simple data/text occurs by differential offset patterns between two or more large, seemingly-identical data files whose content is manipulated at the LSB level to produce low-level difference information between the files. Images, videos, or music files are splendid for this purpose because of the ability of the data bytes to withstand careful manipulation without inherently corrupting the "cover" nature of the file. For example, by shifting the LSB of a pseudo-random sequence of some of the pixels within a large image of the canals of Venice produces an effect that is invisible to the naked eye when viewing the image as a simple graphic. At the same time, unless one has the exact original baseline image for direct comparison, it is impossible to tell that the file has been manipulated or that any encrypted information is contained. And, by using multiple, offset-image encryption files to jointly carry the overall encryption, one can use a rotating scheme of encipherment between the images that makes it impossible for hostile reconstruction to occur unless all the enciphered images plus the baseline are collected together, along with the unique pseudo-random pattern used for the rotation amongst the specific files on a bit-by-bit basis. There are an almost infinite variety of such steganographic encryption variations that can be conceived (and implemented)... making detection and cracking almost inconceivable without a-priori knowledge of the encryption specifics. Because the host files are passive, there is no attention-drawing vector that points to their existence as anything worthy of special attention... especially if they reside in different locations, some being online at different sites or on separate pieces of removable storage media.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
jansson_mark
Markus Jansson
Premium
join:2001-08-05
Finland
1 edit | said by Blackbird  :Right off, that means the software used to create and embed the encryption must, itself, not ordinarily reside on the same system as the encrypted material, else a direct vector is created to cue the analyst onto how best to seek out encrypted products related to that software. And the encrypted material must not self-betray its existence. Well, thats what I had in mind too...program could be for example named to something else and carried with you in USB-hdd etc...then with a touch of button it would dismount all volumes, wipe its program files and (after uninstalling it first) driver and clean the registry from its existance. From my post at Truecrypt forum:
quote:
1a) Create "traveller version" that automatically, once launched, disables "recent documents" from working so that no information about files launched from the encrypted volume will remain. Ofcourse programs like Word still keep list from files being opened so maybe users should use CCleaner too but anyway...
1b) And, once TC is exited, deletes the registry keys and driver from the hdd.
1c) And also has capability to read-only-mode for containers/drives if user is working only with user level permissions.
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | |
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
·Verizon Online DSL
| said by jansson_mark : ...program could be for example named to something else and carried with you in USB-hdd etc...then with a touch of button it would dismount all volumes, wipe its program files and (after uninstalling it first) driver and clean the registry from its existance. From my post at Truecrypt forum: quote:
1a) Create "traveller version" that automatically, once launched, disables "recent documents" from working so that no information about files launched from the encrypted volume will remain. Ofcourse programs like Word still keep list from files being opened so maybe users should use CCleaner too but anyway...
1b) And, once TC is exited, deletes the registry keys and driver from the hdd.
1c) And also has capability to read-only-mode for containers/drives if user is working only with user level permissions.
Unfortunately, that still leaves some kind of control or housekeeping program resident on the encrypted drive to govern the OS's use of encryption-intended drive sectors. That will still betray the presence of the encryption methodology in use. Unless, of course, one doesn't use such a resident control program and simply takes the chance that the OS or a disk utility won't "puppy-track" all over even a few of the encrypted sector elements. Because if that happens, the plaintext beneath will be toast.
Obviously, if the inherent encryption algorithm is strong enough, it should nevertheless withstand a lot of attack even should its presence get betrayed. But still... an undetected encipherment is an unbroken encipherment, no matter what power the analysts' tools possess.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
jansson_mark
Markus Jansson
Premium
join:2001-08-05
Finland
| quote:
That will still betray the presence of the encryption methodology in use. Unless, of course, one doesn't use such a resident control program and simply takes the chance that the OS or a disk utility won't "puppy-track" all over even a few of the encrypted sector elements. Because if that happens, the plaintext beneath will be toast.
I explained in my post to Truecrypt forums, that since Windows generally writes to the first available sectors on the hdd, there is very little actual risk of encrypted sectors getting hammered if they are in the area that is near at the end of the hdd.
Ofcourse, one could use this kind of encryption only on secondary partitions or hdd:s, where one would not normally write any (other files)...sure they might be some files present there to "explain" the hdd:s existance, but user would be carefull not to add much more onto the hdd.
Also, if user wants to add files the the hdd/partition where "superhidden" container is, one could simply first MOUNT the "superhidden" container and let the TC protect those sectors from Windows overwriting. Then you could write anything you like in that hdd/partition or inside the "superhidden" container without any fear that container would be overwritten.
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | |
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
·Verizon Online DSL
| said by jansson_mark : I explained in my post to Truecrypt forums, that since Windows generally writes to the first available sectors on the hdd, there is very little actual risk of encrypted sectors getting hammered if they are in the area that is near at the end of the hdd. ... Also, if user wants to add files the the hdd/partition where "superhidden" container is, one could simply first MOUNT the "superhidden" container and let the TC protect those sectors from Windows overwriting. Then you could write anything you like in that hdd/partition or inside the "superhidden" container without any fear that container would be overwritten. Depending on the "value" of the encrypted material, I'm not sure if I'd want to simply trust to Windows "generally" doing anything. Normally, if it's needful to encrypt something, it means it's high-value material in the first place... and not something you'd want to risk to the whims of Windows' "typical" but unspecified behavior. And there's still the issue of certain disk utilities - especially defragmenters - that may routinely shift certain file-types or even ordinary ones to the end of their partitions in order to collect enough contiguous partition free space to "do their thing".
The mounting concept might help with the Windows over-write risks, though you'd have to keep the superhidden container mounted at all normal-usage times, then remove all traces completely when you wanted the drive encryption to become covert - and hope that nothing Windows subsequently did while in that state would cause harm to the encryption sectors. But 'mounting' would probably run afoul of certain disk utilities, many of which need the computer environment to be simple and basic, with all other material "turned off" or unmounted before running... and that's the very thing you wouldn't want if the utilities should happen to habitually shuffle the encrypted partition's cluster deck in order to do their job.
Whatever encryption scheme were used, along the lines you've described, it must be strongly covert and randomized with regard to its nominal starting-point sector usage and the general layout of subsequent encrypted locales. If such a scheme were deployed, it's a sure thing that the expert analysts would become immediately aware of it and routinely check any target drives for characteristic usage patterns or attributes of end-of-drive bit-pattern placement that might yield to machine analysis to betray the presence and nature of the overall encryption technique used. Once that cat was out of the bag, the heavy-duty cracking focused on the specific discovered encryption technique would begin.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
·Verizon Online DSL
| reply to jansson_mark
Some added thoughts on all this. Steganography is, in and of itself, not inherently a typical encryption process. It is actually an obscuration process. All it basically attempts to do is to hide a plaintext string (or whatever) within a relatively complex data field, be that a written message, a visual image, "normal" mathematical tables, computer files, etc. What it offers, if performed properly, is a highly-undetectable "envelope" carrier for whatever information is embedded within. But the key to a typical successful steganograph is for it to remain covert. That is, its role as a carrier of information within must remain undetected.
In actual practice, the steganography realm often blurs and merges into the encryption realm. Rather than simply embed plaintext characters (or digital representations thereof) directly into the carrier data, one or more encryption-like processes are additionally employed to protect the plaintext even should the steganograph be detected as such. That encryption can be conventional upon the plaintext, with direct embedment of the encipherment into the carrier. Or it can be integral to the steganographic process - i.e. the use of pseudo-random placement of the next plaintext character within the carrier data or the use of pseudo-random rotation of placing that next character between one of several carrier data objects or files.
Typically, top-notch steganography will do both. That is, it will first conventionally encrypt the plaintext into encipherment, then integrally super-encrypt that cipher text pseudo-randomly into multiple, similar data objects or files. Decryption then requires all the steganographs plus the baseline, along with the algorithm seeds for the stegano-encipherment and for the basic encipherment. The advantage is that, unless someone slips up procedurally, every element of the process stands alone as completely undetectable in being a carrier for the steganographed data. Retrieval simply means accessing all the steganographs, knowing the seeds, and reversing the process... a rather easy task for covertly and securely communicating plaintext to whomever. Especially if the carrier steganographs are posted on separate, ordinary-looking websites and the baseline is an "ordinary" data object present on all the players' computers. Typically, the only risk is data corruption of any of the carrier files themselves along the way - unless somebody is "looking down from above" to monitor which files are moving where all over the Internet and is able to detect and recognize the activity as steganographic... then they still have to crack it and any underlying encipherment.
There are all sorts of variations on these principles. One can use a widely-held, invarient baseline object/file and have a separate listing of which baseline characters represent the next character of the plaintext stream... that is, an Ottendorf cipher. But that means the key is the character-location listing, and it must be undetectably stored or conveyed to a recipient. This is not that easy, since it so clearly appears to be what it is: a key. Detection of the key means the analyst then has to either determine what is the widely-held baseline object or else directly attack the Ottendorf key's listing - which, unless superencipherment was employed, does readily lend itself to language-frequency cracking.
Or one can use an invarient baseline data pattern held securely by the author (and recipient, if any) and create slightly-offset clones whose offset patterns themselves convey the underlying plaintext... that is, ordinarily-understood steganographs. That means the baseline must be securely stored and the encipherment product must be undetectably stored or conveyed - which is remarkably easy if the baseline and carrier are each a fairly complex graphics image, music file, or video whose minor alteration remains undetectable by normal viewing means.
In your process, the hard drive itself becomes the steganographic carrier. Location of the critical clusters is the steganographic algorithm, and the removable-media-based software is the 'key'. Strong data encryption (TC-like) would also likely be applied to the critical data before embedment to obtain a super-encryption effect. Ordinarily, that would be sufficient to avoid detection. However, if the "key" must leave behind predictable tell-tale processes, files, or tables to govern the OS or disk utilities in preventing corruption of the encipherment, then such tell-tales become readily-detected vectors to the presence of the steganograph. Once detected, a single steganograph is no more secure than any other encipherment technique... which is why multiple steganographs are sometimes used with image steganography - successful cracking would require all the steganographs together. But to not leave the tell-tale behind to continue governing disk writes would risk the corrupting effects of the OS and/or disk utilities over-writing or relocating the critical clusters... and corrupted encipherment means unretrievable plaintext.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL
 ·Verizon FIOS
| reply to jansson_mark
For secure steganography, write the data to unallocated blocks, then overwrite it with a single pass of zeroes. Plenty of people in this forum can tell you how easy it is to recovery the overwritten data with software.
 | |
dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL
·Verizon FIOS
| reply to Blackbird
The approach taken in StegFS seems to be to create enough redundancy (i.e., extra copies of data) such that you can stand to lose a lot of it.
»www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf | |
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
·Verizon Online DSL
| said by dave :The approach taken in StegFS seems to be to create enough redundancy (i.e., extra copies of data) such that you can stand to lose a lot of it. » www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf StegFS does contain some interesting concepts, and the redundancy scheme indeed represents a more than passable attempt to deal with over-write corruption issues. But, at least in the form described, StegFS leaves footprints betraying its presence, either via its files or via the recompiled kernel needed to support it (unless one uninstalls its files completely and also reinstalls the original UNIX kernel, trusting the encrypted drive fragments totally to the not-so-gentle ministrations of OS over-writes). I'm also wondering how rapidly the scheme's attributes deteriorate as the disk/partition fills more and more with normal files - especially the overwriting percentage vs. redundancy-level measurements they describe.
The idea of "plausible deniability" put forth by the authors may carry some merit in kinder, gentler locales... but I'd not want to face the consequences of being found to be using StegFS in other, far harsher political climes. Some adversaries will assume the worst and work backward from that, only as one proves himself less than fully guilty. So for such an environment, plausible deniability becomes plausible culpability to the maximum possible software capability. And, given that analysts can read as well as you or I, they'd be quite aware of what maximum security levels StegFS was capable of. In that case, God help the accused user who only made actual use of 2 or 3 of the security levels - how could he ever prove there was nothing at level 15? Obviously, a lot depends on what one is trying to protect, where that occurs, and what the local consequences of compromise or even use-detection might be.
In the blackest of worlds, I'd never trust a steganographic system that left any externally-perceivable footprints, especially adjacent to or internal to the enciphered material... I'd want the steganographs to be stand-alone, with no compromising details anywhere in sight - preferably located on distant website(s) to give me some maneuvering space and time. I guess "hidden in plain view - somewhere else" has some elemental appeal. But many folks' needs can certainly vary widely from that...
I was frankly surprised that the processing "hit" for StegFS was only 6-200:1 for various operations... I'd have expected something so complex and in some ways so elegant to slow things down much more than that.
--
If God wanted us to work with electrons, He'd make them big enough to see... | |
|
