CSE 227: Lecture 4


The topics covered in this lecture are security mechanisms and how they relate to the security goals, the concept of the trusted computing base, and assignment 1.

Security Mechanisms

The following is a list of security mechanisms that we came up with in class, plus a couple of additional related ones. It is, of course, not an exhaustive list of all possible security mechanisms.
  1. Passwords (something you know)
  2. Door badges / security tokens (also sometimes used for logging on) (something you have)
  3. Biometric devices (something you are) We see in movies (Thunderball and Charlie's Angels) how biometric devices used for security -- and are bypassed....
  4. Secure hash functions (crypto; not covered in any detail in this class)
  5. File system access controls (unix: chmod; NFS: get/setfacl; etc)
  6. System resource limits (unix: get/setrlimit); important for availability
  7. Sandboxing
  8. Security kernels
  9. Public key cryptography (crypto; not covered in any detail in this class)

Trusted Computing Base

The Trusted Computing Base (TCB) is the hardware and software that is used to implement the security mechanisms. It is everything that must be trusted to work in order for the security mechanisms to work: the CPU's security mechanisms (e.g., kernel vs user mode), the operating system security kernel, system programs such as /bin/login, etc.

We also compared the security assumptions for accountability, comparing those needed for public key cryptography -- digital signatures -- with those needed for system audit logs. For public key, in the absence of key exposure, we must assume that the software implementing the crypto is correct, in addition to the underlying OS that supports the crypto software. We have to believe that the OS is not making the secret key available to attackers, or if the secret key is encrypted (as in the case for PGP or GPG), that keystrokes aren't being made available. The underlying OS's TCB must be secure.

With system audit logs, obviously the system's TCB must be secure as well. Does this mean that there is no need for non-repudiation based on digital signatures? Digital signatures allow non-repudiation even in the context of distributed systems, esp when systems are in different administrative domains (but not different public key infrastructures or disjoint Certification Authority hierarchies). Furthermore, with audit logs the system event logging is much more tightly coupled with the OS and is typically used for different purposes (e.g., post mortem analysis), whereas signatures are used for proof of origin (of messages) and for authorization (e.g., signing a SET transaction).

Reading Assignment

Read Ken Thompson's Turing Award lecture. Write a summary of the key ideas from this paper (an ASCII text file; no more than one page) and email this to me by midnight Friday Jan 18.
[ search CSE | CSE | bsy's home page | links | webster | MRQE | google | yahoo | citeseer | certserver ]
picture of bsy

bsy+cse227w02@cs.ucsd.edu, last updated Mon Apr 8 20:19:51 PDT 2002. Copyright 2002 Bennet Yee.
email bsy.


Don't make me hand over my privacy keys!