Some questions on encryption/decryption
Eric Lee Green
>So OK they have seized your ScramDisk with the secret financial records
>and correspondence your ex girl friend wants get her hands on for a
>palimony suit. Or you're dead and your heirs want to know where the
>boodle is, or the cops do. or the bankruptcy court. Or maybe you
>just don't want your heirs to know what a real pervert you were
>in life. Whatever.
>
>So how do they go about decoding your ScramDisk?
If you're dead, they're out of luck.
If you're alive, why, the judge simply asks you for your passphrase and
tosses you in jail for contempt if you refuse to provide it.
I have not looked at the ScramDisk code so I have no idea how well its
encryption works (I am not a Windows user), but if they did it right,
you will not decrypt the thing without the passphrase.
--
Eric Lee Green er...@badtux.org http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
STEELEYE
Bast...@Paris.gov wrote:
>So OK they have seized your ScramDisk with the secret financial records
>and correspondence your ex girl friend wants get her hands on for a
>palimony suit. Or you're dead and your heirs want to know where the
>boodle is, or the cops do. or the bankruptcy court. Or maybe you
>just don't want your heirs to know what a real pervert you were
>in life. Whatever.
>
>So how do they go about decoding your ScramDisk?
>
The easiest method, and the one most likely to be used, is to install
a hardware keylogger, or surveillance software, on your system and
steal your passphrase.
Of course, this would have to be done while you're still alive and
using the computer. It wouldn't be an option if you are already
dead. But then, if you're dead, you'll have much bigger problems
to deal with than worry over somebody getting your stash from
your ScramDisk - like the rigors of shoveling coal into a red-hot
furnace 24 & 7.
>How can they tell what encryption method you used? Do they need to know?
>
>How can they tell how big an encryption key you used, 40 bits? 128? 256?
>
>How can they tell how long a passphrase or password you used? Can they
>determine the pass phrase without knowing in advance how long it is? If
>the encryption method can accept a phrase 256 bits long and you use only
>64 bits (eight characters), can they determine that they only have to
>find the 64 bits and not 256 bits?
>
>If you use only 64 bits and fill the rest of the pass phrase with spaces
>to fill out the 256 bits, have you in effect made a 256 bit pass phrase?
>How would they break that?
.
nemo outis
all jurisdictions baed on English law:
I wouldn't count on the 5th amendment - maybe good enough, maybe not.
I'm not saying I agree with the argument, but a judge could say something
like, "Decrypting your hard disk is not testimony against yourself. It is more
like being forced to open a safe in your office that may contain evidence.
You have no constitutional right to obstruct or impede the obtaining of such
evidence. Comply or be found in contempt!"
And you definitely want something more than some form of "weak denial" such as
you forgot your password (which won't help you). The burden of proving
inability to comply with a court order lies with you and will be decided by
the judge on a "balance of probabilities." That's the *same* judge who issued
the original order who will be adjudicating inability to comply and deciding
on finding you in contempt! Guess which way he'll lean!
The standard of proof (yeah, proof!) for inability to comply has gotten much
tougher in light of a recent, much-celebrated US case on asset-protection
trusts, the Anderson case. Ignore the topic of the case (asset-protection
trusts) and whether the Andersons buggered up (they did) and just read what
standard the judge set for them not to be found in contempt (they were) in
claiming inability to comply. One good discussion (there are many) can be
found at:
http://www.sirex-llc.com/BDKPC/andersons.htm
Your methods of denying ability to comply (e.g., I forgot my password) might
stand up, but if a judge thinks you are jerking him around he can jerk back
pretty hard!
Regards,
In article <3ac24...@news4.newsfeeds.com>, Bast...@Paris.gov wrote:
>In article <slrn9c3rm...@edesk.inhouse>, er...@badtux.org says...
>>
>>
>>If you're alive, why, the judge simply asks you for your passphrase and
>>tosses you in jail for contempt if you refuse to provide it.
>
>Has this issue been resolved? As long as I have the Constitution here:
>
>"AMENDMENT [V.] No person...shall be compelled in any criminal case to be a
>witness against himself."
>
>That quite simply says the judge may not compel you to divulge your pass
>phrase if doing so could result in a criminal case or if they have already
>instituted a case against you. As for immunity, forget it. What they did to
>Susan MacDougall was cruel and unusual punishment that quite plainly deprived
>her of her Constitutional rights, with the courts' connivance. And there is
>simply no way a court or anyone else can overcome plain memory loss. Nor could
>anyone ever prove you had it written down somewhere, quite probably in plain
>sight. Mine is. I don't have it in memory but there is also no way that anyone
>could put together the elements that comprise it from items in plain sight, nor
>
>could I put it together away from those elements, which would probably be
>removed and jumbled up in any sort of half-assed search.
>>
>In any case, if one is the target of a Tempest attack, wire taps, etc., then
>one has bigger problems than playing around with encrypted data intended to
>keep the heirs or the vengeful girl friend out of one's affairs.
>
nemo outis
bloody sure that there's nothing defiant or "nudge, nudge, wink, wink" about
it. If there's even a smell of intention to thwart justice (as perceived by
the judge!) then the judge will ram your clever story so far up your arse that
you can taste it! If there isn't a law or precedent, believe me, he'll find
one! (Do you really think they play by the rules if you push them to
"hardball?")
It's not just a question of being polite (although that helps a lot). If the
court finds that you were doing a pretty good job of remembering the password
for months or years and then suddenly forgot it when a charge was laid then
you're going to fail that "balance of probabilities" test. Smart lawyers will
also grill you on your phone number, SSN, etc. You must be consistent in how
good a memory you present. Is that possible? Sure, but it takes planning and
rehearsal - don't underestimate the sphincter-pucker-power of a lawyer with
20 years of experience interrogating you, possibly before a judge with years
of assessing the credibility of witnesses, especially since the judge in
making a finding of contempt has extraordinary discretion and latitude. Yeah,
it can be done, but don't be cavalier about it.
The first and most important rule is: Never come to their attention. Once you
do you're 90% dead, even with a good story, good encryption, a good lawyer,
etc. At best you're going burn up a lot of time and energy and come out with
a lot thinner wallet!
I'll tell you what I use: data kept offshore (Belize) with a split-key system
for retrieval. My data exists to protect joint-venture business info and can
only be opened with the help of an offshore confederate (a two-key system like
nuclear missiles). I have company cheques to prove contactual relationships,
correspondence, lawyer-drawn-up non-disclosure agreements, etc. going back
several years to verify this. The offshore confederate will not agree to
disclosure. Even so, I bite my nails.
I rely on some specifics of Canadian law to help me (based on advice by
Thorsteinsson's - one of the best tax law firms in Canada) such as the
protections provided by jointly-owned property. My data also has a claim to
client-solicitor privilege since that's who is the offshore agent/confederate
I have the agreement with. Paranoid? You bet!
For less important stuff I upload/download a .wav stego-Scramdisk to/from one
of the free storage services, never leaving it on my machine past the period
of use.
Regards,
In article <MPG.152c31202...@news.alt.net>, *@*.com wrote:
>In article <c6sw6.21910$wj1.3...@news1.rdc1.ab.home.com>,
>nemo_...@hotmail.com says...
>>: Your methods of denying ability to comply (e.g., I forgot my password) might
>
>>: stand up, but if a judge thinks you are jerking him around he can jerk back
>>: pretty hard!
>>:
>>: Regards,
>
>Obviously - but all you have to do is cause "reasonable doubt." Who
>hasn't forgotten a password? The judge certainly has at one time or
>another. Say the drive hasn't been opened in months since you forgot
>it, make the appearance of an honest attempt to open it, writing down
>various combinations of a certain combination of upper/lower case
>letters, random characters, and numbers - so it looks like the correct
>password was so hard to remember it's no friggin wonder you forgot!
>
>Attitude is a key - look like you are really, really trying to cooperate
>and remember. Giving him the finger and saying "Sorry man, I just
>forgot (or refuse to remember) and you might have found new
>accomodations courtesy of the government.
>
nemo outis
test! And the guy who gets to make the call is the same judge who issued the
order. And, except in extraordinary circumstances, there's no appeal from a
finding of contempt!
Regards,
In article <MPG.152c31202...@news.alt.net>, *@*.com wrote:
>In article <c6sw6.21910$wj1.3...@news1.rdc1.ab.home.com>,
>nemo_...@hotmail.com says...
>>: Your methods of denying ability to comply (e.g., I forgot my password) might
>
>>: stand up, but if a judge thinks you are jerking him around he can jerk back
>>: pretty hard!
>>:
>>: Regards,
>
Eric Lee Green
>protections provided by jointly-owned property. My data also has a claim to
>client-solicitor privilege since that's who is the offshore agent/confederate
>I have the agreement with. Paranoid? You bet!
A word of warning there: Some judges here in the U.S. have ruled in
the past that a conversation is not priviliged just because you had it
with your attorney. It has to be a conversation in which your attorney
is serving as your attorney and not as your confederate in crime. This
came up in some "mob" cases where the Mafioso were careful to include
their attorney in their planning meetings. These meetings were
bugged. The attorney tried to get the bugged meetings sealed as
priviliged attorney-client communications. The court concluded that
the attorney was serving as a confederate here, not as an attorney,
and thus the recorded conversations were admissible as evidence.
I have no idea how this played out upon appeal. It was just an interesting
little tidbit I picked up in passing somewhere.
nemo outis
true here in Canada. That's why you must be careful to have a plausible and
legal "presentation" reason for the relationship. In fact, one section of the
Canadian income tax act has recently been strengthened to make lawyers,
accountants, etc. directly culpable for any planning advice they provide. The
Ontario bar association howled like monkeys!
Regards,
Don Ocean
S...@NoWay.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> er...@badtux.org (Eric Lee Green) wrote:
>
> >On 28 Mar 2001 06:01:43 -0600, Bast...@Paris.gov <Bast...@Paris.gov> wrote:
> >>So OK they have seized your ScramDisk with the secret financial records
> >>and correspondence your ex girl friend wants get her hands on for a
> >>palimony suit. Or you're dead and your heirs want to know where the
> >>boodle is, or the cops do. or the bankruptcy court. Or maybe you
> >>just don't want your heirs to know what a real pervert you were
> >>in life. Whatever.
> >>
> >>So how do they go about decoding your ScramDisk?
>
> 0000000000000001, nope, 0000000000000002, not it, 0000000000000003, etc
> >
> >If you're dead, they're out of luck.
> >
> >If you're alive, why, the judge simply asks you for your passphrase and
> >tosses you in jail for contempt if you refuse to provide it.
>
> Not if you're in the Good Ol' US of A. In the US, you say "I respectfully
> decline to answer that under the protections afforded to me by the 5th
> Amendments." Which is why you never write down your passphrase. Written, it
> is subject to subpoena. Memorized, it has to come from you, and is
> protected.
************************************************************
That is unless you are granted immunity. And then they might dream up something
else gleaned from the exposed passphrase.
>
>
>
> >I have not looked at the ScramDisk code so I have no idea how well its
> >encryption works (I am not a Windows user), but if they did it right,
> >you will not decrypt the thing without the passphrase.
>
> -----BEGIN PGP SIGNATURE-----
> Version: N/A
>
> iQA/AwUBOsQZtC/mcRXFoh+WEQJO6ACeK3VlmejS0x2kds0Z9x9/uT5b+1MAoJdk
> vpkmeJnaW9pJ9JXepPIIJKHz
> =Plft
> -----END PGP SIGNATURE-----
Eric Lee Green
>er...@badtux.org (Eric Lee Green) wrote:
>>>So how do they go about decoding your ScramDisk?
>>
>>If you're alive, why, the judge simply asks you for your passphrase and
>>tosses you in jail for contempt if you refuse to provide it.
>
>Not if you're in the Good Ol' US of A. In the US, you say "I respectfully
>decline to answer that under the protections afforded to me by the 5th
>Amendments." Which is why you never write down your passphrase. Written, it
Ask Susan McDougal about that.
Until the Supremes sing on the subject, conclude that you WILL see the
inside of a jail cell if the court asks you subpoena (under penalty of
law) to produce your records (stored in encrypted form on your hard
drive) and you "take the 5th". Are your records the encrypted files,
or the decrypted files? The Supremes have not sung on that subject,
unless it was recently (somebody who more carefully covers the Supreme
Court may correct me here). In the meantime, many courts may decide
that the subpoena covers the decrypted files, and cite you for
contempt if you refuse to provide them.
Now, the nicest thing would be if your passphrase merely unlocked a
keyblock in the scramdisk, and you could destroy the scramdisk by
doing a secure overwrite of the passphrase. Then all the subpoenas in
the world are not going to get it back. To make this work, though, you
must do it before the Federales smash in your door with a battering
ram and seize your computer for evidence of possession of DVD-playing
software that allows you to play your DVD's on Linux and
FreeBSD. Unless you've had the forethought to rig your hard drive with
a radio-detonated explosive device, your data, fully intact, is now
under police protection and you're once again faced with the "produce
your records or go to jail for contempt" scenario.
--
Eric Lee Green er...@badtux.org http://www.badtux.org
Thomas Shaddack
>In article <slrn9c97q...@edesk.inhouse>, er...@badtux.org says...
>>
>
>>Now, the nicest thing would be if your passphrase merely unlocked a
>>keyblock in the scramdisk, and you could destroy the scramdisk by
>>doing a secure overwrite of the passphrase. Then all the subpoenas in
>>the world are not going to get it back.
>
>Hmmm. How would one do that?
There could be a solution; tamperproof ROM/RAM disk, IDE-compatible. Mount
it into a standard machine as a boot drive, initialize the key, install the
necessary software, have fun.
A scramdisk key can be relatively pretty short. Enough to fit to two square
millimeters of RAM chip, backed up by a battery. I bet my shoes the
software that would be able to simulate the IDE interface for the disk
could be put to a small microcontroller, maybe even a gate array (for
acronym lovers, FPGA). The disk itself can quite easy be just combination
of EPROM and SRAM chip, with their address spaces overlaid. (The magic is
that we need to simulate a whole disk with filesystem. Most of the
filesystem is read-only and nonvolatile; there is only a small area of what
has to 'vanish' on command. The disk itself will be stored as byte-per-byte
image in the EPROM (a meg or two fits to a single chip today), with the
area that is 'vanishable' mapped to the SRAM chip. Means that the
controller reads from the EPROM unless it reads the keyfile; then a bit
flips on Chip-Enable lines and it reads from SRAM instead.
The IDE has few commands; read sector, write sector, few more. We need to
do the cylinder:head:sector translation to 512-byte sectored offsets of the
memory space. This can be pretty simple. Either a simple formula, or just a
lookup ROM table; we don't need many sectors here anyway. The disk doesn't
have to include all the most modern IDE instructions; think an equivalent
of one of the first ancient 10(or whatever)-meg IDE disks - they should be
still able to operate even in the most modern PCs.
We don't need to implement the Write-Sector commands, except for filling in
the disk key. But maybe even that could be better to do through "vendor-
specific" command, to avoid accidental overwriting of the key if Billy's
Darling (aka Windoze) would throw a tantrum.
Other good vendor-specific commands could be disabling the unit's
sensitivity for specified time, thus allowing computer's transport or
service, or erasing the key area (ie when brute-force attempt of passphrase
guessing is detected) as parallel method to physical tamper detection.
This method could be the best compromise; security on physical level,
without having to use pyrotechnic devices, (still) fully legal. When the
computer gets seized and transported off-site, the tamper-detection unit
fires up and the disk 'forgets' the key. You then can freely give out
unlocking passphrase and even otherwise fully cooperate. It can be even
possible that the unit would generate the key on its own, as one of the
"vendor" commands, during of the process of unit initialization. Then no
human will have even theoretical chance to know the keyfile content, so not
even rubberhose cryptoanalysis can reveal anything. (Ruling out TEMPEST or
trojan attacks.)
If the outputs of the computer are secured (hardware-level disabled ports
(ie, cutting certain leads of the driver chips, to be really sure, or
physically removed connectors), no floppy drive, etc.), we are more or less
immune even to grabbing of the passphrase by means of keylogger or so. (It
will get out. It isn't possible to get the data from the unit without
tampering it. At the moment of tampering, the disk key is "forgotten".)
If the unit would be realized by just swapping the controller board on an
old, nonfunctional harddrive for the ROMdisk one, the presence of such unit
in the computer - without booting it - should be not obvious even in case
of checking the case content by x-rays.
Checking the case screws and case position is simple - thin wire or
switches, and mercury switch (beware of earthquakes). We have to somehow
make sure it will not be possible to get inside the box by other means, ie.
by drilling a hole in the case or the front panel. (Make the box sealed,
and use light detector inside that will trip the key destruction? Checking
of the unit would be logically drilling a hole into it and putting
'endoscope' inside and shine there to see, either in visible light or
infrared - cover both.) Sealing the ROMdisk in block of epoxide resin (with
thin uninsulated wires from the battery in few loops around the block's
body, and then buried in another epoxide layer - so even in case of having
access to the unit the attempt to cut away the resin will cut the wires
(thus cutting off power from the RAM) and attempt to dissolve the resin
will most likely make the wires short (with loss of backup power voltage))
will make it more secure.
For much greater flexibility, it should be possible to use FEPROM chips and
add vendor instructions to flash in new content for the disk's sectors,
thus making it upgradable.
For security reasons, enabling of flashing new content should be linked
with erasing of the disk key - which will prevent malicious modifications
of the code by a trojan.
The key maybe shouldn't be writable in from outside at all - the unit
should have onboard hardware random number generator, new keys will be
generated by vendor-instruction request. Unlocking the vendor-specific
instructions could be one separate specific instruction requiring certain
parameters, thus preventing a mishap in case of operating system going awry
in even the weirdest way.
One of the sectors could be separated for unit internal status reporting,
like backup battery status, or incremental counter of power-on attempts,
etc. This could be mapped to a binary file that will be interpreted and
displayed on startup.
More details about this idea for request.
Permission to crosspost it anywhere where smart EE people willing to design
this device is granted automatically, if possible with quoting the source.
In such case, if technically possible please keep me updated about
development status of my "child".
Please comment on this. I want to know where I done mistakes or what could
be done better.
Shaddack, the Mad Scientist
Bruno Wolff III
>>>keyblock in the scramdisk, and you could destroy the scramdisk by
>>>doing a secure overwrite of the passphrase. Then all the subpoenas in
>>>the world are not going to get it back.
If you take action to destroy the evidence after you have been ordered
not to, you can get in big trouble.
It is possible to set up a system where the private key is in volatile
memory and will be permanantly lost if the system is shut down as is
normally the case when evidence is seized. The private key can be generated
without any record of what it is.
However if you do this you better spend a lot of effort to make sure the
machine stays up and be prepared to lose the data on ocassion. For some
applications it may make sense to run things this way.
As an additional safety factor, you good require a seperate key (or biometric
data) to be entered periodically or else the private key will be wiped. This
protects you if someone secures the equipment without powering it off. They
will only have a limited time frame to order to produce the data after
which it will no longer be possible for you to recover it.
Eric Lee Green
>Bast...@Paris.gov wrote in <3ac4c082$1...@news4.newsfeeds.com>:
>>In article <slrn9c97q...@edesk.inhouse>, er...@badtux.org says...
>>>Now, the nicest thing would be if your passphrase merely unlocked a
>>>keyblock in the scramdisk, and you could destroy the scramdisk by
>>>doing a secure overwrite of the passphrase. Then all the subpoenas in
>>>the world are not going to get it back.
>>
>>Hmmm. How would one do that?
>
>There could be a solution; tamperproof ROM/RAM disk, IDE-compatible. Mount
>it into a standard machine as a boot drive, initialize the key, install the
>necessary software, have fun.
I've come to the conclusion that secure erase must be implemented at the
in the drive firmware, via erasing a keyblock.
Note that flash disk cards exist up to about 110 megabytes. These implement
an IDE hard drive on a flash card. Usually these are plugged into PCMCIA
ports for hauling files around between laptops, since they are less
bulky than diskettes and are less likely to fail.
One problem is that current custom processor chips used inside hard drives
do not have the horsepower to do encryption. They have hardware to do the
sophisticated ECC calculations that modern hard drives do, and they have
hardware to handle streaming data from disk to buffer, and they have
hardware to handle streaming data from buffer to I/O interface, but
the actual processor itself is quite weak. So even if we knew the
firmware programming instructions for a particular disk drive (and most
disk drives ARE programmable, though for obvious reasons those
specifications are not published!), the actual hardware just does not have
the horses.
is another possibility. Consider a NAS device. You could build one in
a case you got from Rat Shack using the little widgets these guys
make. It would be slow (10base T and a 100 mhz 80486), but you don't
possess the keys anywhere. You feed the widget a password and it
allows you to log in. The actual data shares are encrypted loopback
devices, and the keys to those encrypted loopback devices live in
RAM. No power, no keys. Now, typical thud'n'blunder cops come in, grab
all your computer hardware, what do they do? They toss it all in the
back seat of a cop car and head off to the local cop shop, at which
point they start calling around looking for someone who actually knows
something about computers to do something with all this gear they just
seized. Now, first thing that's going to happen is that they're going
to plug in your computer and it's going to complain that it can't
mount its shares. Next thing that's going to happen is that they're
going to look around and try to find the shares, and figure out that
the little box that looks like a cable modem is where those shares
actually are. Then they try to mount them, and it asks for a
password. They don't know the password, and of course, you did not
tell them a password. Next thing they do is look into the NAS box.
Hmm, tiny battery-powered CPU hooked up to an IDE drive (NOT hooked to
the battery). So they, what do they do next? You guessed it, they
remove the IDE drive, and go put it into try tossing the IDE drive
into a normal system, and it boots up into Linux. But the encrypted
loopbacks don't come up because the keys were in the ramdisk. But they
don't know that, they just figure that you're hiding some keys
somewhere. So they toss it all in an evidence locker, and the wheels
of justice turn until some months later, a judge orders you to turn
over the password. You do so. They type it in. Nothing
happens. Nothing *CAN* happen, because the battery keeping the CPU and
RAM going in the NAS box has died several months ago and the keys are
gone.
The problem is that you'll have a difficult time explaining that it is
technology, not willful stubbornness, that is preventing you from
turning over the files. As far as the cops are concerned, you're just
giving them the wrong password. About the best argument you could make
is that it's not your fault that the police did not follow proper
procedures and ended up inadvertantly wiping out your data. After all,
you cannot produce files that the police accidentally destroyed via
incompetence. Whether that would be "bought" or not, is another question.
Here in Phoenix, a jury recently convicted a man of murder for killing
his wife. There's no witnesses, and only the sketchiest of circumstantial
evidence -- but the man is a complete and total jerk, he refused to
follow his attorney's advice and insisted upon testifying, and the
jury decided that being a jerk was enough of a reason to convict him of
murder. Juries can be capricious that way. Judges, too, if they think
you're giving them the run-around.
Marc
>One problem is that current custom processor chips used inside hard
>drives do not have the horsepower to do encryption.
The computer that is supposed to read data from the drive has enough
horsepower to decrypt the data. There is no need to have the drive
itself decrypt it. If you like to store your key in SRAM, you can
build a parallel port dongle (or USB if you prefer that). The key
can be requested by the computer BIOS, and the dongle can decide to
comply or deny.
Eric Lee Green
The problem there is that the key is being requested by the
computer. Now it's quite easy for TLA's to insert a piece of software
into your computer that intercepts the key at the time that it is used
to decrypt the encrypted drive. Think about how Scramdisk works. A
good hacker working for a TLA could make a version of Scramdisk that
saved its key in plain view somewhere in the encrypted data. If the
TLA siezes the computer later, that key can be used to decrypt the
scramdisk, even though the TLA may not have the dongle anymore.
That's why the "encryption appliance" model, where the actual device
does the encryption and decryption. The dongle will work to foil your
local cop shop, but in my opinion it's just too darned easy to
subvert.
--
Eric Lee Green http://www.badtux.org mailto:er...@badtux.org
Phoenix Branch -- Eric Conspiracy Secret Labs
Cruisin' the USENET since 1985
Thomas Shaddack
<slrn9ceph...@edesk.inhouse>:
>On 1 Apr 2001 12:31:02 GMT, Marc <ma...@aargh.franken.de> wrote:
>>>One problem is that current custom processor chips used inside hard
>>>drives do not have the horsepower to do encryption.
>>
>>The computer that is supposed to read data from the drive has enough
>>horsepower to decrypt the data. There is no need to have the drive
>>itself decrypt it. If you like to store your key in SRAM, you can
>>build a parallel port dongle (or USB if you prefer that). The key
>>can be requested by the computer BIOS, and the dongle can decide to
>>comply or deny.
Actually, much better would be something that would be placed between the
disk and the IDE controller, and behave in transparent manner, invisible
from the app level. Authentication either by a smartcard, or by a
passphrase, or by just any other method or combination of methods. The
disks themselves aren't trustful enough (who knows what's lurking in the
firmware, also there is the wear compensation thing when the sectors going
to fail are copied to spare sectors, the problem I pointed to in one of the
previous threads).
>The problem there is that the key is being requested by the
>computer. Now it's quite easy for TLA's to insert a piece of software
>into your computer that intercepts the key at the time that it is used
>to decrypt the encrypted drive. Think about how Scramdisk works. A
>good hacker working for a TLA could make a version of Scramdisk that
>saved its key in plain view somewhere in the encrypted data. If the
>TLA siezes the computer later, that key can be used to decrypt the
>scramdisk, even though the TLA may not have the dongle anymore.
Just after each boot from non-writable media, integrity checks of all
relevant files have to be done. The files must have sources available for
code scrutiny, if there aren't backdoors or vulnerabilities.
There could be also BIOS integrity check. Though in case of hardware-
disabled flashing and no physical access to the machine's inside chance of
BIOS breach is nil.
Then load the decryption routines for the big disk. Load the key. Check the
files if their checksums are what they should be, before even thinking
about running them.
As alternative solution, you can have a table of clusters that are non-
modifiable, keep checksums of their encrypted form, and do the check even
before allowing access to the encrypted disk.
Takes some fun from installing software and so, but it's the price of
security. After all, you can always have two machines - one for common work
and games, one for security-sensitive issues. Black and red zone.
If you really need to transfer data (ie, emails) between black and red
machines, I think you wouldn't risk much by using ie. serial cable as a
link. But the secure machine must be ALWAYS the one in control of the link
(the insecure one should have no say on what files to send), and NO
executable code should be allowed to enter the secure machine.
>That's why the "encryption appliance" model, where the actual device
>does the encryption and decryption. The dongle will work to foil your
>local cop shop, but in my opinion it's just too darned easy to
>subvert.
Yes, exactly.
The solution with the RAM/ROM disk I proposed (still requesting
comments!!!) will work in limited way, as long as a trojan app will not get
ahold of the key stored in computer's memory. Which can be reached when
ABSOLUTELY NO untrusted software is run on it. But it is common practice
for trusted systems; to reach higher level of certification a machine has
to NOT be connected to any kind of networks. EACH AND EVERY piece of
executable code brought from outside can potentially carry a trojan
payload.
For further briefing about system security see DoD 5200.28-STD, aka DoD
Trusted Computer System Evaluation Criteria, aka Orange Book.
Just my $0.02...
Shaddack, the Mad Scientist
Eisvogel
|Just after each boot from non-writable media, integrity checks of all
|relevant files have to be done. The files must have sources available for
|code scrutiny, if there aren't backdoors or vulnerabilities.
|
|There could be also BIOS integrity check. Though in case of hardware-
|disabled flashing and no physical access to the machine's inside chance of
|BIOS breach is nil.
|
|Then load the decryption routines for the big disk. Load the key. Check the
|files if their checksums are what they should be, before even thinking
|about running them.
|As alternative solution, you can have a table of clusters that are non-
|modifiable, keep checksums of their encrypted form, and do the check even
|before allowing access to the encrypted disk.
That is good for ruling out any tampering while you are away from your system.
By contrast it is not going to protect you against any kind of trojan etc.
cause you would trustfully generate the signs for those files too.
|Takes some fun from installing software and so, but it's the price of
|security. After all, you can always have two machines - one for common work
|and games, one for security-sensitive issues. Black and red zone.
The *first* and essential step.
|If you really need to transfer data (ie, emails) between black and red
|machines, I think you wouldn't risk much by using ie. serial cable as a
|link. But the secure machine must be ALWAYS the one in control of the link
|(the insecure one should have no say on what files to send), and NO
|executable code should be allowed to enter the secure machine.
Put a two-sided firewall in the middle.
|The solution with the RAM/ROM disk I proposed (still requesting
|comments!!!) will work in limited way, as long as a trojan app will not get
|ahold of the key stored in computer's memory. Which can be reached when
|ABSOLUTELY NO untrusted software is run on it. But it is common practice
|for trusted systems; to reach higher level of certification a machine has
|to NOT be connected to any kind of networks. EACH AND EVERY piece of
|executable code brought from outside can potentially carry a trojan
|payload.
Not only executeables, but almost any type of data file like html, doc ...
For the RAM/ROM check the m-o-o-t project.
Eisvogel
--
if(FBI || CIA || KGB || MAD || M6)
{
System.shutdown();
}
Thomas Shaddack
<slrn9coq5k....@localhost.localdomain>:
>|Then load the decryption routines for the big disk. Load the key. Check
>|the files if their checksums are what they should be, before even
>|thinking about running them.
>|As alternative solution, you can have a table of clusters that are non-
>|modifiable, keep checksums of their encrypted form, and do the check
>|even before allowing access to the encrypted disk.
>
>That is good for ruling out any tampering while you are away from your
>system. By contrast it is not going to protect you against any kind of
>trojan etc. cause you would trustfully generate the signs for those
>files too.
IS! Only to certain extent, though.
The signs are generated at the moment the system is trustfully clean, and
are used to verify it stays clean, that it hadn't been accidentally
contaminated. The signs then can be stored in one-time-writable part of the
ROM disk.
>|Takes some fun from installing software and so, but it's the price of
>|security. After all, you can always have two machines - one for common
>|work and games, one for security-sensitive issues. Black and red zone.
>
>The *first* and essential step.
Also, protects against bringing in a trojan.
>|If you really need to transfer data (ie, emails) between black and red
>|machines, I think you wouldn't risk much by using ie. serial cable as a
>|link. But the secure machine must be ALWAYS the one in control of the
>|link (the insecure one should have no say on what files to send), and
>|NO executable code should be allowed to enter the secure machine.
>
>Put a two-sided firewall in the middle.
Don't use standard network connection. A standard serial terminal should be
pretty bulletproof; the code required is simple, and there are transport
protocols that allow transferring files over such link. (Remembering times
of BBS and Zmodem transfers; principially similar. Or I think there was
think like Kermit.) Anything that requires packet driver is too complicated
to be *really* secure. Also, this method requires to willingly run a
terminal software, manually connect to the insecure machine, and
download/upload files from there. No way how the insecure machine could
initiate the file transfer itself.
>|machine has to NOT be connected to any kind of networks. EACH AND EVERY
>|piece of executable code brought from outside can potentially carry a
>|trojan payload.
>
>Not only executeables, but almost any type of data file like html, doc
Javascripts can be considered executables, document macros as well. Secure
machine should have all scripting disabled, if possible by physical removal
or damaging (ie, zeroing key function names in the binary file) of the
required libraries, to prevent accidental enabling.
Yes, it is not comfortable. But for comfort we have the 'black' machine;
the 'red' one is for security.
If the security is real issue, I suggest to not run Windows on the machine
at all, and use unix-based OS. But this depends on what you want to do on
that machine; if it is only for ie. accounting, or if you do a topsecret
R&D on it.
>... For the RAM/ROM check the m-o-o-t project.
Sounds familiar... URL? :)
Shaddack, the Mad Scientist
--
... if(TLA)system.forgetkeys();