Buffl

Prüfung 2

JO
by Julia O.

Classical Principles for Protected IT Systems

Saltzer and Schröder 1975

  • Historical starting point ensuring security in Multics operating system (1974), Unix (1974), …

Economy of mechanism: Used security mechanisms and processes must be simple to use that they can be applied automatically and routinely

  • „Keep the design as simple and small as possible.“

Fail-safe defaults: Base access decisions on permission rather than exclusion

  • „The default situation is lack of access.“

Complete mediation: It forces a system-wide view of access control and implies that a foolproof method of identifying the source of every request must be devised

  • „Every access to every object must be checked for authority.“

Open design: The design of a system should not be secret, and all protection mechanisms must be open

  • „No security through obscurity.”

Separation of privilege: No single accident, deception, or breach of trust is sufficient to compromise the protected IT system

„Two keys“, „Multi-factor …“

Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job

  • „Just-Need-to-know security rule“

Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users

  • „Restrict processes to one user only (if possible)“

Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly

  • „Mental image of user’s protection goals matches the mechanisms to use“


HTTPS Workflow



  1. The SSL or TLS client sends a "client hello" message that lists cryptographic information such as the SSL or TLS version and, in the client's order of preference, the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the "client hello" to include the data compression methods supported by the client.

  2. The SSL or TLS server responds with a "server hello" message that contains the CipherSuite chosen by the server from the list provided by the client, the session ID, and another random byte string. The server also sends its digital certificate.

  3. The SSL or TLS client verifies the server's digital certificate.

  4. The SSL or TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key.

  5. If the SSL or TLS server sent a "client certificate request", the client sends a random byte string encrypted with the client's private key, together with the client's digital certificate, or a "no digital certificate alert".

  6. The SSL or TLS server verifies the client's certificate.

  7. The SSL or TLS client sends the server a "finished" message, which is encrypted with the secret key, indicating that the client part of the handshake is complete.

  8. The SSL or TLS server sends the client a "finished" message, which is encrypted with the secret key, indicating that the server part of the handshake is complete.

  9. For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.


Author

Julia O.

Information

Last changed