CSE 127: Lecture 2

The topics covered in this lecture are Availability, Confidentiality, Integrity, Traceability/non-repudication, TCSEC: TCBs, Tempest Security,

under construction

next time: distributed systems: finish up on confidentiality by covering briefly DES/AES as standard symmetric block ciphers and covering in more detail RSA as a standard asymmetric (public key) scheme; cover integrity and non-repudiation.


Availability is the notion that resources should remain usable by the authorized users. This is often a difficult security property to provide, especially in distributed systems -- distributed denial of service (DDOS) attacks are difficult to prevent.


Confidentiality refers to the notion that application/user data that is confidential can be protected from unauthorized access. In some systems, there is an explicit Mandatory Access Control (MAC) policy where data is marked with a sensitivity label, and users and their processes are marked with an access clearance. In other systems such as Unix or Windows, the access control is called Discretionary Access Control (DAC) -- it is up to the owner of the file to control access, via either the RWX access bits or an Access Control List (ACL). This can be thought of as ``read'' access to a file.

In distributed systems, confidentiality of messages is typically provided by encrypting the communications.


Integrity refers to the notion that data cannot be modified without appropriate authorization. The same MAC/DAC ideas apply. The type of access correspond to ``write'' access. Note that the ability to read the data is not required to (over)write it.

In distributed systems, integrity of messages is typically provided by sending the message with a cryptographic checksum.


Traceability and non-repudiation refer to the idea that users can be held accountable for their actions. This means that ``significant'' operations are logged by the system, and that users must authenticate themselves to use the system, so their identities are known. This means that there has to be a login process, which attaches a user-ID to every process that run as a result of the login. What gets logged depends on what ``signficant'' means, and the system programmers must take care to identify all security relevent events and include code to generate log entries.

In distributed systems, digital signatures are associated with request messages; the digital signatures cannot be falsified (unless the user releases his/her private key), so by logging the digital signatures an audit trail can be created. Note that great care must be taken to ensure that the signed message contain enough context information or a ``nonce'' value which is recorded to prevent re-use: otherwise an attacker might be able to take a digitally signed request from an earlier exchange and reuse it inappropriately to implicate a legitimate user. This sort of attack is known as a replay attack.


Tempest Security


These are links additional security-related information. Exploring them is optional unless otherwise stated.

For for information about on-going activities in improving syslog, see SDSC's syslog.

Hacking hot rods

[ search CSE | CSE | bsy's home page | links | webster | MRQE | google | yahoo | citeseer | pgp certserver | openpgp certserver ]
picture of bsy

bsy+cse127.w03@cs.ucsd.edu, last updated Thu Jan 16 12:09:33 PST 2003. Copyright 2003 Bennet Yee.
email bsy.

Don't make me hand over my privacy keys!