12 September 2002

Question & Answer Sessions

1. Where is Becki?

On her way to the bar.

2. Is Dave New the latest victim of a Pitt Bull Terrier?

(a) You should see the other guy! (b) Never under estimate how sharp a piece of Melamine can be.

3. Bootable Solaris CDs?

The Solaris install disks are bootable.

Try making a 2.88 floppy image and write it to the beginning of a CD.

4. Mandrake + XFree86 = bad refresh (no donut). What's up?

Try fiddling the refresh rate a little at a time. Or look for other config files (XF86Config.4 for example).

5. Red Hat problem with mouse/keyboard going away exiting X; have to
reboot. What's up with that?

What the heck are you doing leaving X? A few guesses made, but those approaches were already tried.

6. How do I deal with bounces going back to my MX site.

"I just procmail the #@%$ out of them." -- MRW

7. Has anyone used snort? If so, impressions?

"snort rules." -- several voices

There's a PHP GUI at that's nice.

8. Nanog in Eugene?

EMV is going, MJO is not.

9. Troy is looking for roommates. What to be one?

Talk to Troy.

10. Jobs?

Msen is looking for a junior-level sysadmin.

McKinley Real Estate is looking for an IT manager.

Several people looking for jobs. If you need bodies, post something to the mailing list.

11. How do you expunge the hate that is xdm from Dread Hat?


Will rpm do it?

Change the default runlevel.

12. Anyone used webdav? If so, impressions?

It's a file transfer protocol tacked on to http (Apache has it).

No one has tinkered with it, however.

13. Looking for a software for bandwidth and latency testing. Any
suggestions? (Traffic generation, latency generation, etc.)

FreeBSD dummynet should do everything you want.

14. Any use for a flowpoint DSL router that has occasional problems?
(Recently pulled out of circulation?)

No takers.

16. When are we going to have a swap-meet?

Be careful what you ask for.

17. Any sources for cheap wireless cards, other than eBay?

Micro Center in Madison Heights ($10 after rebate, when they're having a sale, $15-ish otherwise). You've got to root around the place.

18. ATA I86 VOIP over NAT?

Some limited experiences. No idea what the NAT IP actually does, though.

19. What happened to question 15?

It was replaced by the second copy of question 22.

20. Groove is in the heart?

Peer-to-peer shared workspace for business people.

21. Suggestions for floppy/cd firewalls?

PicoBSD. CloseBSD - download, burn a CD, and go.

22. Java virtual desktop/file-share?

"Rooms" was around years ago and there may be things that have built on that.

"BTW, the Java version of eRoom will trash your machine." -- Anon.

22. Suggestions for nifty USB keychain do-dads?

Contact Tullio Proni or Chris Oesterling.

23. Why does SCS have that book?

It was only $1 for Shel Silverstein's "Where the Sidewalk End's" in Hebrew.


Mark Corner talks about:  Zero-Interaction Authentication

This is a research project, not a product, so there are some aspects that 
are not complete.


How does a device know who is typing?
   typically something you know:  password
   something you have:  smartcards
   something you are:  biometrics
   all of these are done once and assumed to hold forever

This is acceptable for PCs:  have relatively high physical security 
when someone is in my office, I know it

Doesn't work for mobile devices:  relatively low physical security

   Seattle-Tacoma airport found 330 laptops in three months
   physical possession does not equal authentication

So what?  If device is lost, an imposter [... missed the rest of this one ...]


   protect data by constantly authenticating user
   keep usable by having something answer for the user

Authentication token:  provides this ability

   worn by user for increased physical security
   enough computational power for small cryptographic tasks
   communication via short-range wireless network

Restores parity between physical possession and authentication


   Threat model
   how is the machine protected?
   how does the machine depend on the token?
   how do we improve performance


   Linux prototype system with iPAQ handheld token


   what is the cost of protection
   what overhead does ZIA add
   how fast can the machine be secured and recovered?


Focus on foiling physical possession or proximity

   inspection and removal of disk, probing physical memory
   exploitation of wireless link
      eavesdropping, modification, insertion

Cannot protect against certain kinds of attacks

   remote exploits
   trojan horses
   trusted, but malicious, users


Protect file system data from physical possession attacks

   all data on disk must be encrypted
   ensure user is present from each use of data
   user retains long-term authority to decrypt

Can't contact token on every instance of use

   adds latency to otherwise sort operations

Take advantage of caching already used in file systems

   on-disk information is kept encrypted for safety
   cached information is unencrypted


Tokens cannot decrypt file contents directly

   small, battery-powered:  limited computation
   connected to laptop via wireless link

      latency comparable to disk, bandwidth much less

Instead, store file encryption key on disk, itself encrypted 

   key-encrypting key never leaves token


Key acquisition time can be expensive

   one network round trip + processing time
   this requires milliseconds
   can't add this to every disk operation!

Two mechanisms mitigate this problem

   overlap key acquisition with disk reads (similar magnitudes)
   cache decrypted keys so they are available during writes

Neither mechanism helps new file creation

   is an asynchronous write: nothing with which to cache
   nothing you read beforehand:  caching cannot save you


What is the right granularity for file keys?

   large size compromises more data in case of key exposure
   small grain limits opportunity for overlapping/caching

We chose per-directory keys

   leverage access patterns
      files in same directory tend to be used together
      acquisition time amortized across a directory
   simplifies key management
      keys are stored in hidden file inside directory
   access rights are on a per-directory basis
      admits per-directory sharing, similar to AFS


Optimizations reduce laptop/token interactions

   high locality, low creation rate:  never decrypt a key!

Add periodic polling to refresh authentication

   cryptographic challenge-response protocol
   need not be frequent, since people are slow

When token does not answer

   assume user is absent, protect all data on machine
   must be fast enough to foil theft

When user comes back into range

   restore machine to "pre-departure" state
   must appear as if machine never changed:  no faulting in!

[... okay, where were we? ...]


Key question:  what to do with cached data on departure?

One alternative:  flush data on departure, read in on arrival

   flush stop is fast:  write dirty pages, bzero cache
   recovery is too slow:  read entire file cache back


Linux kernel using a stackable file system [data storage abstraction]

Rijndael (AES) used for encryption

User-space daemon for authentication, key requests


Whated to answer a few questions

   what overhead does ZIA impose?
   how long does it take to secure the cache?
   how long does it take to restore the cache

Prototype System

   client system:  IBM Thinkpad 57- PII 366Mhz
   token system:  Compaq iPAQ 3650 Strongarm 200Mhz
   connected by 802.11 network in 1 Mb/s mode

Average cost of key acquisition: 13.9 ms

   similar to the average seek time of drives


Testing typical system operation

Used a Modified Andrew Benchmark

   short version:  copy and compile a source tree
   we use the Apache source code for a larger benchmark
   source code is 7.4 MB, compiled version is 9.7 MB

Compared ZIA to two file systems

   ext2fs:  underlying physical file system
   cryptfs:  FiST's cryptographic file system (+Rijndael)

Careful to start with cold file cache

   report mean, standard deviation for 20 trials


   File System      Time (sec.)   Overhead (vs. ext2fs)
   -------------    ------------  ---------------------
   ext2fs           52.63 (0.30)       --
   Cryptfs          57.52 (0.18)       9.28%
   ZIA              57.64 (0.20)       9.32%

   ZIA is statistically identical to simple encryption.

[... more nifty graphs I won't attempt to reproduce ...]


Many examples of cryptographic file systems

   CFS (Matt Blaze), Cryptfs (Erez Zadok), EFS (Win2K)
   all suffer from the problem of "implied consent"
   once you log in, the file system can forevermore decrypt
   Win2k can ask you to authenticate more frequently

      inconvenient: anecdotally, it is often disabled

Can use a smart card to hold keys (Blaze) rather than in-kernel

   smart card left in machine still has "implied consent"

FiST (Zadok) has been very useful in fast prototyping

   we [Mark, et al] recommend it despite a few sharp corners


Usually, your machine has the long-term authority to act as you

Zero-Interaction Authentication

   user retains long-term authority to decrypt sensitive data
   laptop holds only transient authority
   defends against physically lowing a laptop

Does not change user behaviour

   only user-visible action at (infrequently) login time

Does not noticeably impact performance

   < 10% overhead above raw file system

Protects and restores machine quickly

   encrypts buffer cache within five seconds

Rumor & Innuendo (No names, please)

Ameritech seems to have bought enough of the powers that be and will be providing long distance in the not too distance future.

[ Return to the SEMiSLUG minutes page ]