1 / 23

CMSC 414 Computer and Network Security Lecture 12

CMSC 414 Computer and Network Security Lecture 12. Jonathan Katz. Role-based access control. RBAC. Access controls assigned based on roles Can use an access matrix, where “subjects” are roles Users assigned to different roles Can be static or dynamic

cruz-harmon
Download Presentation

CMSC 414 Computer and Network Security Lecture 12

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMSC 414Computer and Network SecurityLecture 12 Jonathan Katz

  2. Role-based access control

  3. RBAC • Access controls assigned based on roles • Can use an access matrix, where “subjects” are roles • Users assigned to different roles • Can be static or dynamic • A user can have multiple roles assigned • Can use “access matrix” with users as rows, and roles as columns • Will, in general, be more compact than a full-blown access control matrix

  4. RBAC: basic idea Users Roles Resources research Server 1 Server 2 marketing Server 3 admin

  5. Questions… • Where might RBAC make more sense than DAC? • Where might DAC make more sense than RBAC? • Advantages of RBAC • Users change more frequently than roles

  6. RBAC reference models • RBAC0 – basic model • RBAC1 – Adds role hierarchies to RBAC0 • RBAC2 – Adds constraints to RBAC0 • RBAC3 – incorporates RBAC1 and RBAC2

  7. RBAC0 • Users, roles, and permissions • A user may have multiple roles, a role may be granted multiple permissions • Session • Maps a user to a set of roles to which the user is currently assigned • Principle of least privilege • Role-to-permission mapping can be fine-grained • E.g., list/modify but not create; append but not modify

  8. RBAC1 • Define a partial order (not total order) on the roles • Inheritance • If role r’ is subordinate to role r, then r has all the permissions that r’ does (and possibly more)

  9. RBAC2 • Adds constraints to user-to-role mapping • Mutually exclusive roles • A set of roles R such that a user can be assigned to at most one role in this set, either overall (static) or per session (dynamic) • Enforces separation of duties • Cardinality • Max. users assigned to a role (e.g., superuser); max roles per user (or per session); or max roles having a certain permission

  10. RBAC2 (continued) • Prerequisite • Mandates that a user can be assigned some role only if already assigned some other role • Can be used to enforce least privilege – a user can specify a weaker role when certain permissions are not needed

  11. Comparing DAC/MAC/RBAC • What would an access control matrix look like in each case?

  12. Trusted Computing

  13. Overview • Secure hardware (“TPM”) installed in computer • Goals • Secure boot • Software verification • Attestation • Encrypted storage • This is already deployed

  14. Disclaimer • The intent of the following is to give the high-level ideas, rather than completely correct low-level details • Full specification available on-line • TCG consortium

  15. TPM chip Non Volatile Storage(> 1280 bytes) PCR Registers (16 registers) I/O Crypto Tools: RSA, SHA-1, …

  16. Non-volatile storage • Endorsement keys (EK) [RSA] • Created at manufacturing time, bound to computer • Signing keys; used for attestation • Storage root key (SRK) [RSA] • Created by user; can be changed • Used to encrypt data

  17. PCR • “Platform Configuration Registers” • 20 bytes; hold SHA-1 output • Can only be modified in two ways (enforced by the hardware): • TPM_Startup (initialize the contents of the PCR) • TPM_Extend(D): PCR = SHA-1 ( PCR || D ) • Used to obtain an “image” of the loaded software…

  18. PCM usage Hardware BIOS boot block OS loader BIOS Application OS measuring TPM Extend PCR • Collision resistance of SHA1 ensures “uniqueness”

  19. What next? • Compare computed value with reference value • Secure boot • Software validation • Verify signature • All this verifies is the source • Decrypt data • Decrypt only if in known configuration • Attestation • Prove to a third party that you are in a good configuration

  20. Encrypted data • Encrypt AES key K with SRK; encrypt bulk data with K • Hybrid encryption! • When encrypting the AES key, embed current PCR value • E.g., SignEK(PCR, EncSRK(K)) • (This is not actually the way it is done) • When decrypting, check that the embedded value matches the current value • Refuse to decrypt if not the case! • Can also incorporate a user password, etc.

  21. Attestation • Goal: prove to a remote party what software is running on my machine • Applications: • Prove to company network that no viruses are running on my machine • Prove to another player that I am running an unmodified version of Quake • Prove to Apple that I am running iTunes…

  22. Basic idea • Sign PCR value with EK • Actually, sign with attestation identity key (AIK) validated with EK (ignore this for now) • Assume third party knows EK • There is actually a PKI • To prevent replay, use nonce provided by the third party • Third party verifies signature; verifies that PCR corresponds to “good” state

  23. Controversy • Loss of anonymity • Signature using EK uniquely identified the machine it came from • Third parties can tell what software you are running • Loss of control • What if google says you need to have google desktop installed in order to use their search engine? • What if Sony says you must use their music player to download their music?

More Related