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.
- Passwords
(something you know)
- Door badges / security tokens (also sometimes used for logging on)
- Mag stripe
- Smart card
- SecureID style
time-based authentication
(something you have)
- Biometric devices
(something you are)
We see in movies
(Thunderball
and
Charlie's Angels)
how biometric devices used for security -- and are bypassed....
- Secure hash functions (crypto; not covered in any detail in this class)
- File system access controls (unix: chmod; NFS: get/setfacl; etc)
- System resource limits (unix: get/setrlimit); important for availability
- Sandboxing
- Security kernels
- Public key cryptography (crypto; not covered in any detail in this class)
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).
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
]
bsy+cse227w02@cs.ucsd.edu, last updated Mon Apr 8 20:19:51 PDT 2002. Copyright 2002 Bennet Yee.
email bsy.