1. Security Overview

2. Security Objectives Confidentiality: prevent/detect/deter improper disclosure of information Integrity: prevent/detect/deter improper modification of information Availability: prevent/detect/deter improper denial of access to services 2 Farkas CSCE 824

3. Distributed applications Authenticity Non-repudiation CSCE 824 3 Farkas

4. Sample Questions What is the trade off between the security objectives? Give an example of the security objectives in the domain of college education. Consider the trend about attack sophistication and intruder’s knowledge. Recommend an approach to enhance the security of future computing systems. 4 Farkas CSCE 824

5. Achieving Security Policy  What to protect? Mechanism  How to protect? Assurance  How good is the protection? 5 Farkas CSCE 824

6. Security Policy Organizational Policy Computerized Information System Policy 6 Farkas CSCE 824

7. Sample Questions Why do we need to fit the security policy into the organizational policy? Why is it recommended to separate policy from mechanism? What does “assurance” mean in the context of security? Give an example security policy enforced on your personal computer/CSE computing system/CEC computing system and recommend security mechanism to implement the policy. 7 Farkas CSCE 824

8. Security Mechanism Prevention Detection Tolerance/Recovery 8 Farkas CSCE 824

9. Security Tradeoffs COST Security Functionality Ease of Use 9 Farkas CSCE 824

10. Threats, Attacks, Vulnerability, Risk  Types of threats  Types of attacks  Relation to security objectives  M(ethod), O(pportunity), and M(otive) of attacks  Methods of defense – Security planning  Risk Management 10 Farkas CSCE 824

11. Risk Management Framework (Business Context) Understand Business Context Identify Business and Technical Risks Synthesize and Rank Risks Define Risk Mitigation Strategy Carry Out Fixes and Validate Measurement and Reporting 11 Farkas CSCE 824

12. Sample Questions Give an example of vulnerability, threat, risk, and attack in the domain of … What does it mean “weakest link” of defense? Recommend a way to increase computing system’s security by incorporating security trade offs into the security planning. Why do we need to understand the business context to have effective security? 12 Farkas CSCE 824

13. Cryptography

14. Insecure communications Sender Snooper Recipient Insecure channel Confidential

15. Cryptographic Protocols  Messages should be transmitted to destination  Only the recipient should see it  Only the recipient should get it  Proof of the sender’s identity  Message shouldn’t be corrupted in transit  Message should be sent/received once only

16. Conventional (Secret Key) Cryptosystem Encryption Decryption Plaintext Ciphertext K SenderRecipient C=E(K,M) M=D(K,C) K needs secure channel

17. Public Key Cryptosystem Encryption Decryption Plaintext Ciphertext SenderRecipient C=E(K pub,M) M=D(K priv,C) Recipient’s public Key (K pub ) Recipient’s private Key (K priv ) K pub needs reliable channel

18. Cryptography Cryptanalyst’s goal:  Break message  Break key  Break algorithm Taxonomy of attacks Breakable vs. unbreakable cryptographic system Properties of good cryptosystem.

19. Cryptosystem Vulnerabilities Passive Attacker (Eavesdropper) Active Attacker Capabilities

20. Basic Encryption Techniques Substitution Permutation Combinations and iterations of these Techniques and attacks ADVANTAGES/DISADVANTAGES!

21. Inherent Weaknesses of Symmetric Cryptography  Key distribution must be done secretly (difficult when parties are geographically distant, or don't know each other)  Need a key for each pair of users  n users need n*(n-1)/2 keys  If the secret key (and cryptosystem) is compromised, the adversary will be able to decrypt all traffic and produce fake messages

22. Product Ciphers One encryption applied to the result of the other E n (E n-1 (…(E 1 (M)))), e.g.,  Double transposition  Substitution followed by permutation, followed by substitution, followed by permutation… Broken for  Chosen plaintext 22 Farkas CSCE 824

23. Trustworthy Encryption Systems Based on sound mathematics Has been analyzed by experts Has stood the test of time Examples: Data Encryption Standard (DES), Advanced Encryption Standard (AES), River-Shamir-Adelman (RSA)

24. Public Key Encryption 24 Farkas CSCE 824

25. CSCE 522 - Farkas 25 Public-Key Encryption Two keys – one is private one is public Solves the key distribution problem (but need reliable channel) Provides electronic signatures Slower than secret-key encryption 25 Farkas CSCE 824

26. CSCE 522 - Farkas 26 Lecture 6 Public-Key Encryption Needed for security:  One of the keys must be kept secret  Impossible (at least impractical) to decipher message if no other information is available  Knowledge of algorithm, one of the keys, and samples of ciphertext must be insufficient to determine the other key 26 Farkas CSCE 824

27. CSCE 522 - Farkas 27 Lecture 6 RSA – Notation C = E(KE-B, M) M = D(KD-B,C) KE-B:public key of B KD-B:private key of B E: encryption alg. D:decryption alg. M:plaintext C:ciphertext 27 Farkas CSCE 824

28. CSCE 522 - Farkas 28 Lecture 6 RSA Both sender and receiver know n Sender knows e Only receiver knows d Modulus: Remainder after division, i.e., if a mod n=b then a=c*n+b Need:  Find values e,d,n such that  Easy to calculate M e, C d for all M < n  Infeasible to determine d give e M ed mod n = M mod n 28 Farkas CSCE 824

29. CSCE 522 - Farkas 29 Lecture 6 Signature and Encryption D EDE A B Plaintext Signed Plaintext Signed Plaintext Encrypted Signed Plaintext A’s private key B’s public key B’s private key A’s public key 29 Farkas CSCE 824

30. CSCE 522 - Farkas 30 Lecture 6 Non-repudiation Requires notarized signature, involving a third party Large system: hierarchies of notarization 30 Farkas CSCE 824

31. Cryptographic Hash Functions 31 Farkas CSCE 824

32. CSCE 522 - Farkas 32 Lecture 8-9 Hash Functions Hash function h maps an input x of arbitrary length to a fixed length output h(x) (compression) Accidental or intentional change to the data will change the hash value Given h and x, h(x) is easy to compute (ease of computation) 32 Farkas CSCE 824

33. CSCE 522 - Farkas 33 Lecture 8-9 Good Hash Function 1. It is easy to compute the hash value for any given message 2. It is infeasible to find a message that has a given hash 3. It is infeasible to modify a message without changing its hash 4. It is infeasible to find two different messages with the same hash 33 Farkas CSCE 824

34. Cryptographic Protocols 34 Farkas CSCE 824

35. CSCE 522 - Farkas 35 Lecture 6 Protocols Good protocol characteristics: Established in advance Mutually subscribed Unambiguous Complete 35 Farkas CSCE 824

36. CSCE 522 - Farkas 36 Lecture 6 Symmetric-Key Distribution: Symmetric-Key Techniques Symmetric-Key without Server Symmetric-Key with Server 36 Farkas CSCE 824

37. CSCE 522 - Farkas 37 Lecture 6 Symmetric-Key Distribution: Public-Key Techniques Simple secret key distribution Secret key distribution with confidentiality and authentication Diffie-Hellman Key Exchange 37 Farkas CSCE 824

38. CSCE 522 - Farkas 38 Lecture 6 Simple secret key distribution SenderRecipient 1.KE-S ||ID-S 2. E KE-S (K session ) Vulnerable to active attack! HOW? Public key of S Secret Session key 38 Farkas CSCE 824

39. CSCE 522 - Farkas 39 Lecture 6 With confidentiality and authentication SenderRecipient 1.E KE-R [N1||ID-A] 2. E KE-S [N1||N2] 3. E KE-R [N2] 4. E KE-R E KD-S (K session ) Assume: KE-R and KE-S are known in advance Nonce Question: Why do we need reliable distribution of public keys? 39 Farkas CSCE 824

40. CSCE 522 - Farkas 40 Lecture 6 Intruder in the Middle Attack JohnRose Intruder Hi Rose, I’m John. Hi John, I’m Rose. Hi Rose, I’m John. Intruder and John Uses Diffie-Hellman To agree on key K. Intruder and Rose Uses Diffie-Hellman To agree on key K’. Question: the attacker may want to have K and K’ be the same, Why? 40 Farkas CSCE 824

41. CSCE 522 - Farkas 41 Lecture 6 Asymmetric-Key Exchange Without server  Broadcasting  Publicly available directory With server  Public key distribution center  Certificates 41 Farkas CSCE 824

42. CSCE 522 - Farkas 42 Lecture 6 Public-key certificates Certificate Authority Sender Recipient KE-S C-S=E KD-CAuth [Time1,ID-S,KE-S] 1. C-S 2. C-R KE-R CR=E KD-CAuth [Time2,ID-R,KE-R] 42 Farkas CSCE 824

43. CSCE 522 - Farkas 43 Lecture 6 Certificates Guarantees the validity of the information Establishing trust Public key and user identity are bound together, then signed by someone trusted Need: digital signature 43 Farkas CSCE 824

44. CSCE 522 - Farkas 44 Lecture 6 Digital Signature Need the same effect as a real signature  Un-forgeable  Authentic  Non-alterable  Not reusable 44 Farkas CSCE 824

45. CSCE 522 - Farkas 45 Lecture 6 Digital signature Direct digital signature: public-key cryptography based Arbitrated digital signature:  Conventional encryption: Arbiter sees message Arbiter does not see message  Public-key based Arbiter does not see message 45 Farkas CSCE 824

46. Identification and Authentication 46 Farkas CSCE 824

47. Authentication Allows an entity (a user or a system) to prove its identity to another entity Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

48. Authentication Information Must be securely maintained by the system.

49. Authentication Requirements Network must ensure  Data exchange is established with addressed peer entity not with an entity that masquerades or replays previous messages Network must ensure data source is the one claimed Authentication generally follows identification  Establish validity of claimed identity  Provide protection against fraudulent transactions

50. User Authentication What the user knows  Password, personal information What the user possesses  Physical key, ticket, passport, token, smart card What the user is (biometrics)  Fingerprints, voiceprint, signature dynamics

51. Passwords Commonly used method For each user, system stores (user name, F(password)), where F is some transformation (e.g., one-way hash) in a password file  F(password) is easy to compute  From F(password), password is difficult to compute  Password is not stored in the system When user enters the password, system computes F(password); match provides proof of identity

52. Vulnerabilities of Passwords Inherent vulnerabilities  Easy to guess or snoop  No control on sharing Practical vulnerabilities  Visible if unencrypted in distributed and network environment  Susceptible for replay attacks if encrypted naively Password advantage  Easy to modify compromised password.

53. Attacks on Password Guessing attack/dictionary attack Social Engineering Sniffing Trojan login Van Eck sniffing

54. One-time Password Use the password exactly once!

55. Lamport’s scheme Doesn’t require any special hardware System computes F(x),F 2 (x),…, F 100 (x) (this allows 100 logins before password change) System stores user’s name and F 100 (x) User supplies F 99 (x) the first time If the login is correct, system replaces F 100 (x) with F 99 (x) Next login: user supplies F 98 (x) … and so on User calculates F n (x) using a hand-held calculator, a workstation, or other devices

56. Time Synchronized Secret key Time One Time Password DES 56 Farkas CSCE 824

57. Challenge Response Work station Host Network Non-repeating challenges from the host is used The device requires a keypad User ID Challenge Response 57 Farkas CSCE 824

58. Access Control 58 Farkas CSCE 824

59. Access Control Protection objects: system resources for which protection is desirable  Memory, file, directory, hardware resource, software resources, etc. Subjects: active entities requesting accesses to resources  User, owner, program, etc. Access mode: type of access  Read, write, execute

60. Access Control Requirement Cannot be bypassed Enforce least-privilege and need-to-know restrictions Enforce organizational policy

61. Access Control Access control: ensures that all direct accesses to object are authorized Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs Need: – Proper user identification and authentication – Information specifying the access rights is protected form modification 61 Farkas CSCE 824

62. Access Control Access control components: – Access control policy: specifies the authorized accesses of a system – Access control mechanism: implements and enforces the policy Separation of components allows to: – Define access requirements independently from implementation – Compare different policies – Implement mechanisms that can enforce a wide range of policies 62 Farkas CSCE 824

63. Closed vs. Open Systems Closed systemOpen System Access requ. Exists Rule? Access permitted Access denied Access denied Access permitted Allowed accesse s Disallowed accesses yesno yesno (minimum privilege)(maximum privilege) 63 Farkas CSCE 824

64. Access Control Models All accesses Discretionary AC Mandatory AC Role-Based AC 64 Farkas CSCE 824

65. Discretionary Access Control Access control is based on  User’s identity and  Access control rules Most common administration: owner based  Users can protect what they own  Owner may grant access to others  Owner may define the type of access given to others

66. Access Matrix Model Read Write Own Read Write Own OBJECTS AND SUBJECTS SUBJECTSSUBJECTS Joe Sam File 1File 2 66 Farkas CSCE 824

67. Grant and Revoke GRANT ON To [WITH GRANT OPTION] ------------------------------------------------------------------------------------------------------------------------------------ GRANT SELECT * ON Student TO Matthews GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS GRANT SELECT(NAME) ON Student TO Brown GRANT command applies to base relations as well as views

68. Grant and Revoke REVOKE [ON ] FROM ------------------------------------------------------------------------------------------------------------------------- REVOKE SELECT* ON Student FROM Blue REVOKE UPDATE ON Student FROM Black REVOKE SELECT(NAME) ON Student FROM Brown

69. Non-cascading Revoke A B C D E F A B C A revokes D’s privileges E F 69 Farkas CSCE 824

70. Cascading Revoke A B C D E F A B C A revokes D’s privileges 70 Farkas CSCE 824

71. Positive and Negative Authorization Problem: Contradictory authorizations GRANT ON X TO DENY ON X TO A B C E D + - + - 71 Farkas CSCE 824

72. Negative Authorization A B C E D + - + - - Positive authorization granted By A to D becomes blocked but NOT deleted. 72 Farkas CSCE 824

73. DAC and Trojan Horse Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Read Employee REJECTED! Black is not allowed To access Employee 73 Farkas CSCE 824

74. DAC and Trojan Horse Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Word Processor TH Inserts Trojan Horse Into shared program Uses shared program Reads Employee Copies Employee To Black’s Employee 74 Farkas CSCE 824

75. DAC Overview Advantages:  Intuitive  Easy to implement Disadvantages:  Inherent vulnerability (look TH example)  Maintenance of ACL or Capability lists  Maintenance of Grant/Revoke  Limited power of negative authorization

76. Mandatory Access Control Objects: security classification e.g., grades=(confidential, {student-info}) Subjects: security clearances e.g., Joe=(confidential, {student-info}) Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject e.g., subject can read object only if label(subject) dominates label(object) 76 Farkas CSCE 824

77. Mandatory Access Control If access control rules are satisfied, access is permitted e.g., Joe wants to read grades. label(Joe)=(confidential,{student-info}) label(grades)=(confidential,{student-info}) Joe is permitted to read grades Granularity of access rights! 77 Farkas CSCE 824

78. Mandatory Access Control Security Classes (labels): (A,C) A – total order authority level C – set of categories e.g.,A = confidential > public, C = {student-info, dept-info} (confidential,{ }) (confidential,{dept-info}) (confidential,{student-info,dept-info}) (confidential,{student-info}) (public,{student-info,dept-info}) (public,{,dept-info}) (public,{ }) (public,{student-info}) 78 Farkas CSCE 824

79. Mandatory Access Control Dominance (  ): label l=(A,C) dominates l’=(A’,C’) iff A  A’ and C  C’ e.g., (confidential,{student-info})  (public,{student-info}) BUT (confidential, {student-info})  (public,{student-info, department-info}) 79 Farkas CSCE 824

80. Bell- LaPadula (BLP) Model Confidentiality protection Lattice-based access control  Subjects  Objects  Security labels Supports decentralized administration 80 Farkas CSCE 824

81. BLP Reference Monitor All accesses are controlled by the reference monitor Cannot be bypassed Access is allowed iff the resulting system state satisfies all security properties Trusted subjects: subjects trusted not to compromise security 81 Farkas CSCE 824

82. BLP Axioms 1. Simple-security property: a subject s is allowed to read an object o only if the security label of s dominates the security label of o  No read up  Applies to all subjects 82 Farkas CSCE 824

83. *-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s No write down Applies to un-trusted subjects only BLP Axioms 2. 83 Farkas CSCE 824

84. Blind Writes Improper modification of data Most implementations disallow blind writes 84 Farkas CSCE 824

85. Trojan Horse and BLP Employee Black’s Employee Brown: read, write Black, Brown: read, write Brown Black Word Processor TH Insert Trojan Horse Into shared program Use shared program Read Employee Copy Employee To Black’s Employee Secret Public Secret  Public Public Secret Reference Monitor 85 Farkas CSCE 824

86. RBAC Motivation Multi-user systems Multi-application systems Permissions are associated with roles Role-permission assignments are persistent v.s. user-permission assignments Intuitive: competency, authority and responsibility

87. RBAC Allows to express security requirements but CANNOT ENFORCE THESE PRINCIPLES e.g., RBAC can be configured to enforce BLP rules but its correctness depend on the configuration done by the system security officer.

88. Roles User group: collection of user with possibly different permissions Role: mediator between collection of users and collection of permissions RBAC independent from DAC and MAC (they may coexist) RBAC is policy neutral: configuration of RBAC determines the policy to be enforced

89. RBAC RBAC 3 consolidated model RBAC 1 role hierarchy RBAC 2 constraints RBAC 0 base model 89 Farkas CSCE 824

90. RBAC 0.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment 90 Farkas CSCE 824

91. RBAC 1.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Role Hierarchy 91 Farkas CSCE 824

92. RBAC 1 Role Hierarchy Primary-care Physician Specialist Physician Health-care provider Inheritance of privileges 92 Farkas CSCE 824

93. RBAC 2.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Constraints 93 Farkas CSCE 824

94. RBAC 3.... U Users R Roles P Permissions. S Sessions User assignment Permission assignment Constraints 94 Farkas CSCE 824

95. Next Class Information Warfare Farkas CSCE 824 95