Index > Authentication > 2021-02-01: Module 1: Trust and Security Models

Module 1: Trust and Security Models

There is a huge amount of raw information in this module.

Scenario: You are entering your login credentials to a website on your phone.

You need to trust:

• Your phone
• your home network
• all intermediary ISPs
• The end server

But trust with what? There are different components of trust.

Trust Anchor - something for which trust is assumed, not derived.

Classic trust models

• Monopoly Model
  • One trust anchor
  • Less trust required
  • single point of failure
• Oligarchy
  • Multiple, independent trust anchors.
  • More trust required
  • Less impact from failure
• Anarchy
  • Everyone is a trust anchor
  • Users must make their own trust decisions
  • GPG web of trust

“Objects” of Trust

• Theoretical Objects
  • Cryptographic algorithms
• Designs and Architectures
  • security models
• Implementations
  • Software Implementations
  • System Implementations

How to verify trustworthiness?

• Theoretical Models
  • Formal proofs, like mathematical
• Designs and Architectures
  • Verified through formal review
• Implementations
  • testing and auditing

The “Trusted Computing Base” (TCB)

Not every component of a computer can be trusted. So, we can isolate and trust the security components.

Note that trust does not make something secure

The TCB should be separated from the rest of the computer by a security perimeter. Access must be protected by a reference monitor. This is typically implemented as a security kernel in an OS.

Apple uses a “secure enclave”

What does a security kernel do?

• Handle user / application request for access to OS resources
• Be:
  • Small
  • Simple
  • Well Defined
  • Independently auditable

Rings and Domains

A domain is a set of objects that a given subject has access to. Modern OS’s use “protection rings” to show domain boundaries. (It’s not just user and kernel space).

My chatbot process (the subject) asks the reference monitor for its database file. The kernel does the actual reading from the disk, and returns the data - but only if the process has the correct permissions to access the files it asked for.

The Orange Book

Trusted Computer System Evaluation Criteria

The book sets forth criteria for evaluating the security of an operating system. One such rule requires the presence of a reference monitor, which controls subjects access to resources.

Levels:

• D
  • For OSs that try for C, but fail
• C
  • c1: discretionary security protection
    • Windows NT, Linux
  • c2: controlled access protection
    • Login logging, audit trail maintenance
    • A well configed linux distro could meet this
• B
  • B1: Labeled Security protection -
    • SELinux
    • possibly AppArmor
  • B2: Structured Protection
    • Security model is formally documented
    • use both MAC and DAC
  • B3: Security Domains
    • This is where having a reference monitor becomes a requirement
• A
  • A1: “Verified Design”
    • Formal models and proofs
    • It will work, it will always work.
  • Beyond:
    • The A1 system is developed/built within an A1 system.

During this section, Prof. opened a jar for his daughter. And the zoom chat did rejoice.

Assurance

Assurance mechanisms guarantee the previous requirements are fulfilled, and that the trusted system is validated as secure/not secure.

Assurance can come from multiple mechanisms:

• Operational Assurance
• Life-cycle assurance
• Continuous Protection Assurance

Prof. did not expand on those points.

“Is it a zero or a one - that’s security. How do we know it is what we think it is? That’s assurance.” - Prof.

What’s a “Separation Kernel”?

It has something to do with VMs.

State Machines

• state is a way that a thing can be
  • typically in a circle
• A transition condition tells what can happen to a state
• states transition to other states

Reference Monitors are NEAT

Recall, the reference monitor is the guardian between an applicant (like a userland process) and some protected resource (like OS syscalls)

• N: Non-bypassable
• E: Evaluable
  • Evaluate the security of the reference model
  • Auditable, evaluate the security in practice
• A: Always-invoked
• T: Tamper-Proof

Terms

What do these mean? Hopefully we find out next class.

• Target of Evaluation
• Protection Profile
• Security Target
• Security Functional Requirements
• Security Assurance Requirement
• Evaluation Assurance Level

Some quick review on due dates and assignments

• There are 5 lab assignments, they are group assignments
• end of module quiz grades are individual
• end of semester peer eval is individual
  • You get a 100% just for doing it
  • But it creates a multiplier for group grades, it has huge impact

Module 1 quiz, due Feb. 13th. 2 hours allocated.

• Mod 1 quiz due feb 13th
• Discussion post due feb 6th
  • Watch the video first
• replies to two peers due feb 13th

There is a second discussion post:

• also due feb 6th
• replies also due feb 13th

Lectures are on Monday, group work is on Wednesdays.

There’s also a list of videos that should be watched by Saturday.

Source summary 1 due Feb 13th.

TL;DR: Go scour every inch of MyCourses for due dates, because they’re everywhere.

---

Index > Authentication > 2021-02-01: Module 1: Trust and Security Models