It's a Presidential Mandate, Feds use it. How come you are not using FDE?

Anne & Lynn Wheeler lynn at garlic.com
Wed Jan 17 21:07:01 EST 2007


Steven M. Bellovin wrote:
> Not necessarily -- many of my systems have multiple disk drives and
> file systems, some of which are on removable media.  Apart from that,
> though, this is reinforcing my point -- what is the threat model?

PC/RT had external scsi disk drive housing ... with scsi disk drive "bricks" that could be removed from the housing and locked in safes (when the owner wasn't physical present). This was later part of the '80s ... twenty some years ago.

nearly 35 yrs ago ... there was this enormous corporate project and all the information on the project was kept strictly confidential. a whole bunch of security features were added to prevent leakage of any of the information. they even went so far as to claim that even I couldn't access the information ... even if I was physical present in the room. It was one of the few times that I actually took the bait ... I claimed it would only take me a few minutes ... I found the location in memory of the authentication routine and patched one byte so all returns from the routine indicated valid authentication (most of the time was spent disabling all access to the machine from outside the room since i didn't want a real compromise).

This is similar ... but different to more recent "yes card" vulnerability ... where the card is asked if the correct PIN has been entered ... and a "yes card" always responds "YES". Would appear to work not only for skimming scenario and counterfeit card .... but also as a MITM-attack with valid card. misc. past posts mentioning "yes card"
http://www.garlic.com/~lynn/subintegrity.html#yescard

In any case, my claim way back then (nearly 35yrs ago) was that the only countermeasure to such physical access was encrypting the data. Later, I even did prototype filesystem as example ... but at the time ... the processor load was excessive (would typically only be justified for small subset of extremely sensitive information).

The project back then was called Future System
http://www.garlic.com/~lynn/subtopic.html#futuresys

and was canceled w/o ever being announced. However there were some comments that the amount spent on the failed future system project would have bankrupted any other computer company.

misc. past posts admitted to haven once risen to the bait in my brash youth.
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/2004g.html#45 command line switches
http://www.garlic.com/~lynn/2006.html#11 Some credible documented evidence that a MVS or later op sys has ever been hacked

The scenario was that if I had physical access ... there were a whole variety of compromises that wouldn't have been possible otherwise .... at least for these class of systems ... small footnote about some deployments ... which i didn't find out until sometime later
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

Note that when it started becoming common for people taking portable terminals and later PCs on the road ... for off-site access (reading email, etc) in the very early 80s ... there was vulnerability study done ... and one conclusion was that one of the most weakest points is a hotel PBX closet ... which resulted in design, build and deployment of custom encrypting 2400baud modems for all off-site dial-in access. 

I'm periodically quite dismayed by the cavalier way that many corporations have treated off-site access over the past 20 years. For other comparison, the corporate network, which was larger than arpanet/internet from just about the beginning until possibly sometime mid-85. 
http://www.garlic.com/~lynn/subnetwork.html#internalnet

required link encryptors on all lines that left a corporate facility ... and sometime in the mid-80s there were comments that the internal corporate network had over half of all the link encryptors in the world (these are things like leased lines ... separate from the encrypting dial-up modems).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list